Neon Analytics can keep your production database humming while giving you a lightning-fast, isolated copy for analytics.
Here’s how it works:
Imagine you have a busy e-commerce site. Every second, customers are browsing, adding to carts, and checking out. This activity generates a constant stream of writes to your PostgreSQL database. Now, suppose you want to run complex analytical queries – perhaps to understand customer behavior, identify popular products, or forecast sales. If you run these queries directly on your production database, they can hog resources, slowing down your live site for everyone.
Neon’s "Read-Only Analytics Twin" solves this. It’s essentially a separate, fully functional PostgreSQL database that’s a near real-time copy of your production data. This twin is optimized for reads, meaning it can handle heavy analytical workloads without impacting your live application.
Let’s see it in action.
First, you need a Neon project. If you don’t have one, sign up at https://neon.tech/. Once you’re in, you’ll see your project dashboard.
To create your analytics twin, you’ll use Neon’s branching feature. Think of a branch as a point-in-time snapshot of your database that you can then evolve independently. For analytics, you want a branch that’s a copy of your main "primary" branch, but optimized for reads.
From your Neon project dashboard, navigate to the "Branches" section. You’ll see your default main branch. Click the "+ New Branch" button.
For the "Base Branch," select main.
For the "Branch Name," give it a descriptive name like analytics-twin.
Leave "Point in Time" as the default (which is the latest commit).
Click "Create Branch."
Neon will spin up a new PostgreSQL instance for this branch. This instance is now a copy of your main branch data. The key here is that it’s a separate instance. Your application continues to write to main, while your analytics tools connect to analytics-twin.
You can find the connection details for your new analytics-twin branch in the "Connection Details" tab on its branch page. It will look something like:
postgresql://[user]:[password]@[host]/[database]?sslmode=require
Where [host] will be a Neon-specific hostname, e.g., ep-example-12345.us-east-1.aws.neon.tech.
Now, configure your analytics tools (like Metabase, Tableau, or even a custom Python script using psycopg2) to connect to this analytics-twin connection string. Point your tools to this database, and you’re good to go.
The magic behind this is Neon’s storage architecture. Instead of copying all the data, Neon uses a shared storage layer. When you create a branch, it’s initially just metadata pointing to the same underlying data blocks as the parent branch. Writes to the main branch will create new data blocks, which are then referenced by main. The analytics-twin branch, because it’s read-only relative to the state it was created from, continues to point to the original, unchanged data blocks. This makes branch creation incredibly fast and space-efficient. When you do need to update the analytics twin with more recent data, you simply create a new branch from main – a quick operation that effectively refreshes your twin.
The most surprising thing about Neon’s branching for analytics is how effectively it decouples read and write workloads without complex ETL pipelines or data duplication. You’re not moving data; you’re just pointing a different compute instance at a specific, immutable state of that data, and Neon handles the underlying storage versioning.
The next step is to explore how to automate the creation of new analytics branches on a schedule to keep your twin reasonably up-to-date.