Neon’s compute sizing isn’t just about picking a number; it’s about understanding the fundamental trade-off between raw processing power and how efficiently that power is utilized by your specific database operations.
Let’s see it in action. Imagine a simple table:
CREATE TABLE products (
id SERIAL PRIMARY KEY,
name VARCHAR(255) NOT NULL,
price DECIMAL(10, 2) NOT NULL
);
INSERT INTO products (name, price) VALUES
('Widget A', 19.99),
('Gadget B', 49.50),
('Thingamajig C', 12.75);
Now, let’s run a query. If our Neon compute size is too small, this SELECT might take a noticeable amount of time, and we’d see higher CPU utilization reported in Neon’s metrics. If it’s too large, we’re paying for idle cycles, even if the query itself is fast.
Here’s how Neon manages this, and what you can control:
At its core, Neon’s compute is managed by virtualcores (vCPUs) and memory. When you select a compute size, you’re essentially choosing a bundle of these resources. A "small" compute might have 1 vCPU and 2 GB of RAM, while a "large" could have 4 vCPUs and 8 GB of RAM. The key is that Neon’s architecture separates storage from compute. This means your data is always there, and you can spin compute instances up and down, or even have them auto-scale, without affecting data availability.
The problem this solves is the traditional database monolith. In the past, if your database got slow, you had to provision a bigger, more expensive server. This was a blunt instrument. You might fix a slow query, but you were still overpaying for the rest of the time. Neon allows for granular, on-demand compute. You can provision a compute size that perfectly matches your peak workload, and then scale it down (or let it auto-scale to zero) when you don’t need it, saving significant costs.
The levers you control are primarily the vCPUs and memory allocated to your Neon compute. You can choose from pre-defined sizes (e.g., small, medium, large) or specify custom amounts. The choice here directly impacts query latency and the number of concurrent connections your database can handle effectively. More vCPUs mean more parallel query execution. More memory means more data can be cached, reducing disk I/O and speeding up reads.
Neon’s compute also has a "scale to zero" feature. If your compute is inactive for a configurable period, it spins down, and you stop paying for compute resources until the next connection or query wakes it up. This is incredibly powerful for development environments, staging, or even production workloads with predictable downtime.
What most people don’t realize is how much the type of workload dramatically shifts optimal sizing. A read-heavy workload with many small, quick queries benefits more from lower latency and more memory for caching. A write-heavy workload, or one with complex analytical queries that need to scan large amounts of data, will benefit more from higher vCPU counts to process those operations in parallel. Just looking at total QPS (queries per second) isn’t enough; you need to understand the nature of those queries.
The next step in optimizing your Neon setup is understanding connection pooling and its interplay with compute resources.