Announcement
I will be speaking at Percona Live 2023 about serverless PostgreSQL. Join us at this event if you are interested!
Introduction
Recently, Percona introduced Percona Builds for Neon (Introducing Percona Builds for Serverless PostgreSQL), which makes it easy to install and experiment with serverless PostgreSQL. And I followed it with how you can run easy experimentations with Neon using Docker (Using Docker To Deploy Neon Serverless PostgreSQL).
Before getting into more details about Neon functionality, we need to introduce two important concepts Neon operates with: Tenants and Data Branches.
Tenants
Multi-tenancy is a software architecture pattern where a single instance of a software application serves multiple tenants, allowing them to share resources like storage, processing power, and memory while maintaining separate, secure access to their respective data.
In the context of databases, a tenant’s data can be logically separated from other tenants’ data in the same database so that each tenant can only access and manage their own data. This is particularly useful in cloud-based applications, where multiple customers or organizations share the same underlying infrastructure to reduce costs and improve scalability.
The key aspect of multi-tenancy is the isolation of tenant data, ensuring that each tenant’s data remains secure, private, and separate from other tenants’ data.
In the case of Neon, the single pageserver already comes with multi-tenant functionality, and at the very least, you must have one tenant to create PostgreSQL compute node instances.
The requirement is that each tenant will operate with its own compute node.
Compute Nodes can be created/destroyed on demand; they are not required if there is no current need to access data for a given tenant.
Data branches
Neon enables you to seamlessly create branches of your Postgres database, enhancing your development workflow. With each code deployment, you can establish a separate branch for your testing environments. This way, developers and testers can obtain a data copy for testing or experimentation without impacting the main data.
Utilizing the “copy on write” method, branches are virtually cost-free. Neon refers to data branches as “timelines,” and these terms are often used interchangeably.
You can think (at least I do) of timelines as GitHub branches. Just keep in mind that data branches can’t be merged back.
In the example above:
- Timeline 1 is branched from the Main timeline after two commits.
- Timeline 2 is branched from the Main timeline after four commits.
- Timeline 3 is branched from Timeline 1 after two more commits to Timeline 1.
And to expand on compute node requirements: each timeline requires a separate compute node to operate (and you can shut down the compute node if you do not need to work with the timeline right now).
There is a restriction to be aware of: each tenant/timeline can have only one compute node.
Schematically it looks like this:
I will show the practical work with tenants/timelines in the following blog post, so subscribe for all updates.
Interested in serverless PostgreSQL?
You are welcome to experiment with Neon using our Docker images.
For feedback and questions, please use our Forums: (Latest Percona Labs/Percona Build for Serverless PostgreSQL topics – Percona Community Forum)
Follow our blog for more information about setups, performance, and unique features of serverless PostgreSQL.
If you want to talk with us about builds for serverless PostgreSQL or stay in touch for future updates – leave your contact details below.
Also, if you are interested in possible Support for serverless PostgreSQL, fill out the Contact form, and I will get in touch with you.
