Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Examples integrating with umbrella elixir, phoenix, etc #3

Open
aislanmaia opened this issue Jan 15, 2024 · 6 comments
Open

Examples integrating with umbrella elixir, phoenix, etc #3

aislanmaia opened this issue Jan 15, 2024 · 6 comments

Comments

@aislanmaia
Copy link

Would be great to have some examples, maybe some repos integrating this package with real elixir projects.

@jamilabreu
Copy link

+1 @mindreframer

@jamilabreu
Copy link

@aislanmaia found this demo repo https://github.com/maxohq/surrealix_demo, but more directed instructions would be amazing!

@mindreframer
Copy link
Member

mindreframer commented Mar 4, 2024

@jamilabreu Yeah, sorry about missing docs. In our project we actually decided to move away from SurrealDB for now and stick to plain Postgres. It solved all the performance troubles we had with SurrealDB with non-trivial amounts of data. Also the visibility and troubleshooting is simpler. Maybe SurrealDB becomes more usable for real-life projects in future, then we will invest more time into documenting the usage of Surrealix, for now this project is not in active use at our company

@lessless
Copy link

@mindreframer what issue did you face with surreal?
Would you advice to approach choosing SurrealDB as a primary data storage with caution?

@mindreframer
Copy link
Member

mindreframer commented May 14, 2024

@lessless we had large rather nested json payloads (JIRA issues), that we were storing in SurrealDB. Not too much, around 30k records. Query performance for single records with relations was good, but doing any searching / filtering / pagination was painfully slow (500ms or longer). Also the indexes at that time were not picked up by the query planner, so that it always had to do a full table scan for any "collections" query.

Those issues were quite visible in Github issues, yet the team was focusing on implementing new features rather than fixing the basics. There were also a couple minor casting issues, documentation discrepancies and overall too much hype around things I personally do not need and less focus on storage basics.
I would suggest generating a realistic amount of data for your app, dumping it into SurrealDB and running some plain queries to see how it performs. Pay attention to the storage amount on the file system, memory usage during non-trivial queries, query execution times, handling of parallel-running queries. Do it with something simple, maybe use their Node.js SDK or similar. This is a throw-away project, do not over-engineer it. See how it works with low digit GBs, how long does it take to create indexes, are queries using them. A database that ignores indexes is mostly useless for real production cases.

See https://surrealdb.com/docs/surrealdb/faqs/#is-surrealdb-ready-for-production-use.

While mine intention was simplifying our stack, it ended up actually complicating it. Switching to Postgres resolved all query issues and I also realized that I did not need the flexibility of SurrealDB that much, as I imagined. Also the tooling around Postgres is so robust, that I could just focus on my app and not bother fixing DB issues.

YMMV, for me it was clear, that it's too early for real production for SurrealDB. Maybe next year it will be more robust, until then this SDK is not maintained.

@lessless
Copy link

lessless commented Jun 2, 2024

Thank you for the detailed feedback, @mindreframer. We have a reasonably large dataset, and our queries can take over a minute to execute without indexes. So, it's a no-go from the onset.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants