# Architecture decisions in Neon

DevFeed: [Architecture decisions in Neon](<https://devfeed.tech/articles/architecture-decisions-in-neon-4986.md>)

Original publisher: [Read original article](<https://neon.com/blog/architecture-decisions-in-neon>)

Author: Heikki Linnakangas

Published: 2022-07-08T09:29:00Z

Content type: article

Language: en

Sources: [Blog -- Neon Docs](<https://devfeed.tech/sources/blog-neon-docs.md>)

Topics: [Database](<https://devfeed.tech/topics/database.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [cloud](<https://devfeed.tech/tags/cloud.md>), [compute](<https://devfeed.tech/tags/compute.md>), [databases](<https://devfeed.tech/tags/databases.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [open-source](<https://devfeed.tech/tags/open-source.md>), [operations](<https://devfeed.tech/tags/operations.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [scale](<https://devfeed.tech/tags/scale.md>), [serverless](<https://devfeed.tech/tags/serverless.md>), [storage](<https://devfeed.tech/tags/storage.md>)

## AI overview

The article explains Neon's architectural decisions for a serverless, cloud-native Postgres service. It focuses on separating storage from compute while preserving full Postgres compatibility without maintaining a fork.

## Source excerpt

The idea behind Neon is to create a new serverless Postgres service with a modern cloud-native architecture. When building for the cloud it usually is a good idea to separate storage and compute. For operational databases such design was first introduced by AWS Aurora 1, followed...