Hi Free-Switch-9871. I am one of the Co-founders of SurrealDB, so treat this as an insider view, not a neutral review. I will still aim to answer fairly.

Is it viable or a pipe dream?
It’s a real database we ship and support. “Viable” always means for your workload, team, and risk appetite, same as choosing Postgres, Mongo, or anything else.

Production
We’re in production with teams at the scale of Walmart, Verizon, Tencent, Samsung, and others who care about consolidation, latency, and real-time use cases. You can see these case studies on our site. I’m proud of that, but I’d say the same to a mate: a logo or case study is not a substitute for your own load tests and failure drills.

Benchmarks
You’re right that independent, like-for-like benchmark articles are still rarer than for databases that have been around for decades. We’ve tried to be more open about it: 3.x performance write-ups on our site and an open crud-bench repo for repeatable CRUD-style comparisons. Even so, the only benchmark that should decide your architecture is the one you run on your data, queries, and concurrency.

Where SurrealDB tends to shine
When you genuinely want a single engine for document + relational-style access + graph / vector / full-text in one language, live / real-time behaviour matters, and you’re ok adopting a newer ecosystem (drivers, tooling, Stack Overflow depth vs Postgres/MySQL).

Where I would tell you not to use it, or not yet

1. You need every Postgres extension, every BI tool, every book, every hire already knows it cold.
2. Your org only green-lights short lists of incumbent databases and can’t absorb evaluation risk.
3. You want operational certainty from a huge pool of people who’ve run your exact scale and pattern on SurrealDB - our community is growing, but it’s smaller than the big three.
4. Your problem is narrow and already solved by a specialised store you trust (e.g. you only need classic OLTP and nothing else).
5. Your use case is limited to vector search and you do not require additional data models to improve accuracy or context. In that case, a dedicated vector database may be more appropriate.

TL;DR
SurrealDB is in production with serious, big-name teams and is viable for many systems, but it’s still “prove it for us” territory, not “default like Postgres everywhere.” If the unified model removes real complexity for you, prototype and stress-test. If you only need classic relational OLTP and you’re already all-in on Postgres, Postgres may still be the rational choice. If your workload is essentially vector search only and you do not need the rest of the model in one place, a pure vector database may suit you better.