Neon vs Valkey

What Neon is

Neon is serverless Postgres that separates storage from compute, which lets it scale to zero when idle and create instant database branches for previews and tests. Branching is the feature that changes workflows: a pull request can get its own copy of production-shaped data without a restore. The trade-off is cold starts on an idle branch and a hosted-only model, so it is not the choice when the database must stay on your own hardware.

What Valkey is

Valkey is a BSD-licensed, vendor-neutral in-memory data structure server descended from Redis OSS 7.2.4. It supports RESP2/RESP3 clients, replication, Sentinel, Cluster, transactions, scripting, Pub/Sub, streams and configurable RDB or AOF persistence. Compatibility is strongest with Redis OSS 7.2 and earlier; Redis Community Edition 7.4+ data files are not compatible. Secure deployment is not automatic and requires network isolation, access control and, where needed, TLS.

What Neon is built to do

Storage-compute separation

Scales compute independently of stored data and suspends it when idle.

Database branching

Creates an instant copy-on-write branch for previews and tests.

Postgres compatibility

Speaks the Postgres wire protocol so existing drivers and tools work.

What Valkey is built to do

Rich data structures

Stores strings, hashes, lists, sets, sorted sets, streams and specialized structures in memory.

Persistence choices

Supports periodic RDB snapshots, append-only logging, both together or no persistence.

Replication and failover

Uses asynchronous replication with Sentinel or Cluster deployment patterns.

RESP compatibility

Supports RESP2 and RESP3 and a documented migration path from Redis OSS through 7.2.

Choose Neon if

• Side projects and prototypes: the Free plan gives 100 compute-unit hours, 0.5 GB and 10 branches per project
• Teams that want Postgres billed by usage with no monthly minimum — Launch is $0.106 per CU-hour and $0.35 per GB-month
• Apps that need database branching for previews and CI

Skip Neon if

• Your database is always on: 100 CU-hours a month is roughly 4 days of a 1-CU compute, so Free will not cover 24/7
• You need HIPAA, SOC 2 reports, private networking or IP allow rules — those are on Scale at $0.222 per CU-hour
• You prefer a flat monthly price; Neon bills compute and storage separately

Choose Valkey if

• Caches, ephemeral state, rate limits, queues, streams and real-time application data
• Redis OSS 7.2-or-earlier migrations validated against the actual client, modules and persistence files
• Teams that can operate protected standalone, Sentinel or Cluster deployments

Skip Valkey if

• The system requires disk-first durability or zero acknowledged-write-loss guarantees
• A Redis CE 7.4+ data file must be opened directly without a supported migration route
• The service would be internet-exposed or deployed without firewall, ACL and recovery controls

Neon: pros & cons

• Real Postgres, not a lookalike
• Branching for preview environments
• Scales to zero, so idle projects cost little
• Cold starts on idle databases
• Newer platform than the incumbents
• Advanced tuning is limited compared with self-managed Postgres

Valkey: pros & cons

• Permissive open source: The server is community-developed under the BSD 3-Clause license.
• Familiar ecosystem: RESP clients and Redis OSS 7.2-era configurations, modules and data formats ease many migrations.
• Flexible roles: Data structures, expiry, scripting, transactions, Pub/Sub and streams cover cache and real-time patterns.
• Scale and availability options: Replication, Sentinel and Cluster support failover and sharding topologies.
• Compatibility has a boundary: Redis CE 7.4+ files are incompatible and future Valkey behavior can diverge.
• Unsafe defaults require hardening: Official guidance warns against direct internet exposure and calls for firewalling, binding, ACL/authentication and optional TLS.
• Durability is configurable: RDB, AOF and no-persistence modes have different data-loss, latency and recovery tradeoffs.
• Cluster consistency limits: Asynchronous replication allows windows of acknowledged-write loss, especially during minority partitions.