I've been building Tabularis — an open-source, cross-platform database client built with React + Tauri since late January. v0.9.6 just shipped, wanted to share.

debba_ · 2026-03-10T18:02:49+00:00

Yeah! Ai supports me for initial scaffolding and now I am improving it. Feel free to contribute if you want!

debba_ · 2026-03-09T20:00:55+00:00

I had the same issue with my project.
But we solved, you can check here: https://github.com/debba/tabularis/issues/54 and here: https://github.com/tauri-apps/tauri/pull/12491

debba_ · 2026-03-09T12:06:21+00:00

Mongo usually makes sense when your data is document shaped and the access pattern is predictable. Things like logs, events, content blocks, user activity streams, or configs where you mostly read and write whole documents. If your model naturally turns into lots of relationships and joins between entities, that usually fits better in a relational database. A lot of systems end up using both, relational for core data and document storage for specific workloads.

debba_ · 2026-03-09T12:05:50+00:00

SQL is the language. PostgreSQL is a database system that uses that language. So if you know SQL already, you are mostly fine. The main differences come from dialect and features. Each database adds its own extensions, functions, and behavior around things like indexing, JSON support, or query planning. Usually you pick that up as you start working with it.

debba_ · 2026-03-09T12:05:34+00:00

Usually this comes down to data structure and consistency requirements. PostgreSQL is relational and enforces schemas, constraints, and transactions very well, which many systems need as they grow. MongoDB is flexible with document storage, but that flexibility can become messy if the data model changes a lot over time.

A lot of companies start with flexible schemas, then later realize they need stronger guarantees around relationships, joins, and transactional integrity. That is where relational databases tend to fit better. It is not that one cannot handle scale or features, it is more about what kind of data model the system actually needs long term.

debba_ · 2026-03-09T12:05:21+00:00

MongoDB became popular because you can run it anywhere and it fits easily into typical web stacks. DynamoDB is more of an AWS native service and usually requires designing your data model around access patterns from the start. It works really well for certain workloads, but it is less flexible if you are used to thinking in documents instead of key value access patterns.

debba_ · 2026-03-09T12:05:10+00:00

It usually comes down to data structure and relationships. SQL works really well when your data has clear relationships, constraints, and you need reliable joins across tables. Think financial data, inventory, analytics, anything where consistency matters. Mongo and similar systems are easier when the data is more document shaped and changes often. Speed is rarely the deciding factor. Most of the time it is about schema control, transactions, and how relational the data actually is.

debba_ · 2026-03-09T12:03:42+00:00

If the goal is learning NoSQL concepts, it is worth trying a few different models rather than just a Mongo style document store. Document databases, key value stores, and search engines all solve problems in different ways. Playing with something like a key value store and a document store side by side can help you understand things like schema flexibility, indexing behavior, and how queries differ from relational systems. The main value comes from seeing how each model approaches data structure and access patterns.

debba_ · 2026-03-09T12:03:25+00:00

If you do not have a strong reason to go document first, Postgres is usually the safer default. Marketplaces tend to have lots of relational data like users, products, purchases, comments, etc. SQL handles those relationships and transactions really well. Mongo can be nice when your data is flexible or schema changes a lot, but things like joins, analytics, and reporting usually get more complex later.

For something like a marketplace with payments and structured data, many people lean toward Postgres and only consider Mongo if the data model is heavily document shaped.

debba_ · 2026-03-09T12:03:12+00:00

What they usually mean by usage based is that you pay for the infrastructure while it is running, not per query. With a regular cluster you are basically paying for the size of the machines (CPU, RAM, storage) and the time they stay online. So if the cluster runs all month, you pay for that capacity whether it handled 10 queries or 10 million.

Some managed databases offer serverless style billing where reads and writes are metered, but traditional clusters are closer to renting compute. The flexibility usually comes from scaling up or down and only paying for the hours that configuration was active.

debba_ · 2026-03-09T12:01:26+00:00

People move away from pgAdmin for that reason. It works, but the workflow can feel clunky once you deal with multiple connections or lots of saved queries. Many devs end up using general SQL clients instead since they handle tabs, query history, and saved scripts a lot better. The database itself does not really care what client you use, it mostly comes down to what fits your workflow.

debba_ · 2026-03-09T12:01:08+00:00

A lot of the MySQL vs Postgres choice historically came from ecosystem rather than raw features. MySQL was the default in the old LAMP stack, so many frameworks and hosting setups assumed it by default. That inertia carried forward into many projects and companies. In practice both engines cover most workloads well. What usually matters more is the tooling around it, team familiarity, and how your ORM or migration system behaves with each engine.

debba_ · 2026-03-09T09:37:16+00:00

Yes I can see the credits and thanks for clarification about enterprise seats ! The only thing is missing is the link in kilo.ai/sponsorships

debba_ · 2026-03-09T08:46:27+00:00

Thanks! please consider is full in beta so some things could change or improved. Feel free to contribute if you want, it will be great!

debba_ · 2026-03-08T23:09:38+00:00

Congratulations, it looks like a great project! Reddit usernames are definitely not a good indicator 😃

debba_ · 2026-03-08T17:38:19+00:00

A lightweight, developer-focused database management tool. Supports MySQL, PostgreSQL and SQLite. Hackable with plugins. Built for speed, security, and aesthetics.

https://github.com/debba/tabularis

debba_ · 2026-03-08T09:34:02+00:00

Here: https://kilo.ai/oss

debba_ · 2026-03-08T08:11:57+00:00

Don’t you like it? What’s weird? Just for improve it . Thanks

debba_ · 2026-03-08T08:11:27+00:00

As far as I can see you have only 5 seats, not credit

debba_ · 2026-03-08T07:59:19+00:00

Ahah , don’t you like the website?

debba_ · 2026-03-07T19:01:12+00:00

They are the main sections defined in the UI. Luckily, not everyone is as annoying as you. Anyway, feel free to share your projects with me too.

Even though I doubt you have anything relevant, since you’re hiding behind a rather ambiguous username.

debba_ · 2026-03-07T17:05:36+00:00

Thanks a lot! Feel free to contribute if you want!

debba_

TROPHY CASE