GoGrab Space — 2025 Database Landscape & Recommendation

Last updated: 2025-11-18 16:32

A practical, citation-backed guide comparing MongoDB with modern alternatives (PlanetScale, Neon, SurrealDB, Couchbase Capella, Firestore/DynamoDB, and vector stores). Includes realtime strategies and a migration decision framework tailored for GoGrab Space.

TL;DR

• MongoDB (Atlas) is still a mature, safe document database with a huge ecosystem and excellent managed offering. Great for document-heavy apps and fast prototyping.
• Modern leaders for 2025 SaaS:
  • Neon (Serverless Postgres) — autoscaling, branching, pgvector; ideal balance of performance, cost, and features for multi-tenant SaaS.
  • PlanetScale (MySQL/Vitess) — horizontal scale, branching, zero‑downtime schema changes; pair with app‑level events or CDC for realtime.
  • Couchbase Capella — document DB with ACID + SQL (N1QL); strong performance if you want a Mongo‑style model with SQL and transactions.
  • SurrealDB — ambitious multi‑model DB (documents + graph + SQL + realtime). Big feature surface, but still maturing; test at your scale.
• Realtime with PlanetScale: Do app‑level events first; add CDC via Vitess VStream or third‑party connectors later.
• Recommendation for GoGrab Space: If you want “modern + stable + fast” → Neon. If you want “massive scale + MySQL” → PlanetScale. If you want a modern doc DB → Couchbase Capella. Keep MongoDB if current system is stable and migration cost outweighs benefits (for now).

1) Where MongoDB sits in 2025

Strengths

• Document‑first storage and developer ergonomics (nested JSON, flexible schema).
• Managed Atlas is polished; global clusters and multi‑region patterns are well-documented.
• Change Streams provide database‑level notifications for realtime pipelines.
• Vector search is available in Atlas, integrated with the broader MongoDB platform.

References

• MongoDB Change Streams (manual): https://www.mongodb.com/docs/manual/changestreams/
• Atlas Global / Multi‑Region: https://www.mongodb.com/docs/atlas/global-clusters/ , https://www.mongodb.com/docs/atlas/architecture/current/deployment-paradigms/multi-region/ , https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution/
• Atlas Vector Search: https://www.mongodb.com/docs/atlas/atlas-vector-search/vector-search-overview/ , https://www.mongodb.com/docs/atlas/atlas-vector-search/vector-search-stage/

Middling

• Big analytics: Dedicated OLAP systems (Snowflake/BigQuery/DuckDB/Postgres extensions) tend to outperform for complex aggregations.
• Transactions: Supported, but heavier vs. mature RDBMS (Postgres/MySQL).
• Reactivity: Change Streams are powerful but carry operational cost (replica sets, resource use).

Weaker vs. “modern” leaders

• Serverless‑native elasticity (scale-to-zero and per-request autoscaling) trails leaders like Neon.
• Relational joins are verbose and slower for relational-heavy models (vs. Postgres/MySQL).
• AI-native: Vector is supported, but specialized/vector-first stacks are often faster; Postgres + pgvector is a strong default.

2) SurrealDB — honest overview

What it is: a multi‑model database (documents + SQL‑like SurrealQL + graph + live queries) with built-in auth/scopes and fine‑grained permissions.

Highlights

• Live queries (LIVE SELECT …) for realtime subscriptions.
• Scopes & access control for per-namespace/per-database auth and row‑level access.
• Multi-model: links/graph traversal + document flexibility.

Performance reality (2024–2025)

• Actively improving; official benchmarks and docs are in progress.
• Some users report slow queries in specific patterns (e.g., deep relations, certain graph traversals, or cloud variants). Treat as maturing and test with your workload.

References

• Live queries: https://surrealdb.com/docs/surrealql/statements/live
• Scopes / access control: https://surrealdb.com/docs/surrealql/statements/define/scope
• Features (README): https://github.com/surrealdb/surrealdb/blob/main/README.md
• Performance best practices: https://surrealdb.com/docs/surrealdb/reference-guide/performance-best-practices
• Benchmarking blog: https://surrealdb.com/blog/beginning-our-benchmarking-journey
• Community reports/issues (examples):
  • https://github.com/surrealdb/surrealdb/issues/4623
  • https://github.com/surrealdb/surrealdb/issues/5615

SurrealDB Cloud price (from screenshot you shared)

• Listed price: $0.021/hour
• Math:
  • Per day (24h): $0.504 USD
  • Per month (30 days): $15.12 USD
  • Per month (31 days): $15.62 USD
  • Per year (365 days): 183.96 USD
• Note: The plan in your screenshot shows single node, up to 16 vCPU, 64 GB RAM, 512 GB storage — strong for dev/staging and early prod. Always confirm the current Cloud specs/limits.

3) PlanetScale (MySQL/Vitess)

What it is: Managed Vitess (originated at YouTube) on top of MySQL 8 with a developer‑friendly workflow (branching, deploy requests, safe migrations).

Highlights

• Branching for schema (and Data Branching® for schema+data copies).
• Zero‑downtime schema changes via deploy requests / safe migrations.
• Horizontal sharding & high availability from Vitess; proven at internet scale.
• Foreign keys: support is available; you can enable or avoid, depending on your design.

Realtime options (practical)

1. App‑level events: emit WebSocket/SSE/GraphQL‑subscription events from your NestJS API immediately after successful writes.
2. CDC pipelines: Vitess VStream is the low‑level primitive that CDC tools use to stream changes for analytics/sync; several third‑party connectors support PlanetScale/Vitess. Use this for background jobs, analytics, or cross‑service sync.
3. Occasional polling for non-critical dashboards.

References

• Branching: https://planetscale.com/docs/vitess/schema-changes/branching
• Deploy requests & safe migrations:
  • https://planetscale.com/docs/vitess/schema-changes/deploy-requests
  • https://planetscale.com/docs/vitess/schema-changes/safe-migrations
• Data Branching®: https://planetscale.com/docs/vitess/schema-changes/data-branching
• Vitess overview/architecture: https://planetscale.com/docs/vitess , https://planetscale.com/docs/vitess/architecture
• VStream / CDC background: https://vitess.io/docs/24.0/concepts/vstream/ , PlanetScale blog on pipelines: https://planetscale.com/blog/building-data-pipelines-with-vitess
• Foreign key constraints (support now GA): https://planetscale.com/blog/announcing-foreign-key-constraints-support , https://planetscale.com/docs/vitess/foreign-key-constraints

4) Neon (Serverless Postgres)

What it is: Serverless Postgres with separate storage/compute, autoscaling, branching, and Postgres ecosystem compatibility.

Why it’s compelling

• Autoscaling compute with storage decoupled from compute.
• Branching and time travel (rewind / branches from past states).
• pgvector extension for vector search (AI/RAG).
• Full Postgres features including Row‑Level Security (RLS) for multi‑tenancy.

References

• Autoscaling architecture (storage/compute separation): https://neon.com/docs/introduction/autoscaling-architecture , https://neon.com/blog/scaling-serverless-postgres
• Branching: https://neon.com/docs/introduction/branching , https://neon.com/docs/guides/branching-intro
• Vector search (pgvector): https://neon.com/docs/extensions/pgvector , https://neon.com/guides/vector-search
• Example guides: OpenAI Cookbook & notebooks (pgvector on Neon):
  • https://github.com/openai/openai-cookbook/blob/main/examples/vector_databases/neon/README.md
  • https://colab.research.google.com/github/neondatabase/neon-vector-search-openai-notebooks/blob/main/neon-postgres-vector-search-pgvector.ipynb
• Postgres Row‑Level Security: https://www.postgresql.org/docs/current/ddl-rowsecurity.html

5) Couchbase Capella (Managed Couchbase)

What it is: A document database with SQL‑like N1QL and ACID transactions, strong performance and caching.

Why consider it

• If you want Mongo‑style JSON but with SQL syntax and ACID support.
• Mature tooling, high performance on read/write heavy workloads.

References

• Transactions / N1QL: https://docs.couchbase.com/server/current/learn/data/transactions.html , https://docs.couchbase.com/server/7.1/n1ql/n1ql-language-reference/transactions.html , https://www.couchbase.com/blog/couchbase-transactions-with-n1ql/

6) Firestore & DynamoDB (for realtime or serverless simplicity)

• Firestore: snapshot listeners for realtime document/collection updates; great DX but less relational power.
• DynamoDB: Streams for near‑realtime CDC; excellent for event‑driven systems; not relational.

References

• Firestore realtime listeners: https://firebase.google.com/docs/firestore/query-data/listen , https://docs.cloud.google.com/firestore/docs/samples/firestore-listen-document
• DynamoDB Streams (CDC): https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.html

7) Vector databases & AI

Even if you choose Postgres/MySQL as primary, you can add vector search for AI features:

• Postgres + pgvector (on Neon): strong default for many apps.
• Dedicated vector stores (Qdrant/Pinecone/Weaviate) for advanced workloads.

(See Neon pgvector references above.)

8) Realtime with PlanetScale — implementation patterns

Pattern A — App‑level realtime (recommended first):

1. Client calls your NestJS API to write.
2. After a successful DB write, your API emits a WebSocket/SSE event.
3. Clients update instantly; PlanetScale remains the source of truth.

Pattern B — CDC‑driven (for analytics/audit/sync):

• Use Vitess VStream (or CDC tools that support PlanetScale/Vitess) to capture changes → push to Kafka/NATS/Redis → fan out to services or WebSocket gateways.

Pattern C — Polling (for less critical dashboards):

• Add updated_at columns; poll deltas every N seconds.

9) Decision framework (Switch vs. Stay on MongoDB)

Switch if you need:

• Serverless elasticity & branching (Neon) or massive global scale (PlanetScale).
• Relational modeling with joins and RLS (Postgres).
• Lower operational complexity for multi‑tenancy and CI/CD.
• AI/RAG with pgvector tightly integrated into Postgres.

Stay on MongoDB if you have:

• A stable, document‑centric system that meets current performance goals.
• Team expertise in MongoDB and an Atlas setup that’s cost-effective.
• No pressing need for branching/serverless/relational joins.

10) Suggested paths for GoGrab Space

Option A — Neon (primary)

• Postgres schema with JSONB for flexible fields.
• RLS for tenant isolation; tenant_id context via session variables.
• pgvector for AI features.
• Realtime: app‑level events; optional Postgres logical replication with Supabase Realtime (self‑host) if needed later.

Option B — PlanetScale (primary)

• MySQL schema optimized for relational core.
• Branching & deploy requests for zero‑downtime changes.
• Realtime: app‑level events; optional Vitess CDC (VStream) for analytics/audit.

Option C — Stay on MongoDB short‑term; plan a phased migration

• Keep Atlas for current services.
• Build new AI/realtime features on Neon or PlanetScale, then migrate service by service.

Appendix: SurrealDB plan math (from screenshot)

• Price: $0.021 USD / hour
• Daily (24h): $0.504 USD
• Monthly (30 days): $15.12 USD
• Monthly (31 days): $15.62 USD
• Annual (365 days): 183.96 USD

These numbers are purely unit-price × time based on the screenshot; verify current Cloud pricing & limits before purchase.

Footnotes / Links

All links cited above are the sources used for claims in this document. For longevity, keep this file versioned and re‑run a quick doc audit quarterly.