kgodey

Thanks for catching this, should be fixed. It was a PNG because I forgot to compress it after making the image!

If you like Mathesar’s approach but need to work with MySQL, FDWs would let you connect a MySQL database to Mathesar for data entry and querying. This could be useful if you also have Postgres data and want to work with both in a single interface, or if you wanted things like cross-database queries between both DBs.

That said, if you’re only using MySQL, FDWs add an extra layer, and something like VisualDB, since it’s built for multi-database support, would likely be a more natural fit. The main advantage of Mathesar in this scenario would be if you want something open source and self-hosted (VisualDB looks like proprietary SaaS) or if you just like our UI and user experience.

As a side note, we _are_ considering adding support for other database backends through Postgres foreign data wrappers: https://wiki.postgresql.org/wiki/Foreign_data_wrappers. If this is something you'd be interested in, please feel free to open an issue on our repo.

NocoDB is a universal database GUI that supports multiple backends, while Mathesar is Postgres-only but deeply integrated with its native features, like using Postgres roles and privileges for access control. NocoDB also adds its own UI-level abstractions on top of database objects, whereas Mathesar directly reflects the database structure. That said, NocoDB has features Mathesar doesn’t yet support, like kanban and calendar views, forms, and more Airtable-like data types.

Baserow is more of an open-source Airtable alternative and doesn’t connect to existing databases at all—unlike Mathesar and NocoDB. It has many of the same UI-driven features as NocoDB, such as different types of views and forms, but it doesn’t function as a database interface the way Mathesar does.

Mathesar, however, has a visual query builder that allows joins and query creation directly from the UI, as well as some data modeling tools, like moving columns between tables and merging duplicate data—neither NocoDB nor Baserow offer these. Mathesar is also 100% open source, while both NocoDB and Baserow follow an open-core model with paid features.

We do want Mathesar to be competitive as an Airtable alternative over time. You can already create a database from scratch (we’re not just a GUI for existing databases), but we’d likely need more data types, views, and integrations before it can match Airtable across a broad set of use cases.

And Postgres is definitely amazingly versatile! That's one of the reasons we were comfortable focusing on it as the only supported DB backend for now.

Thank you! Where would you need to hide these fields?

If you had some time, it would be great if you could make a GitHub issue with more details about your use case! https://github.com/mathesar-foundation/mathesar/issues

I think they're pretty different use cases. LibreOffice Base and Kexi are desktop database frontends focused on local databases, while Mathesar is web-based, self-hosted, can be connected to a remote database, and built for multi-user collaboration.

We don't have the capacity to do that internally, but we were thinking about having a "Community Guides" section of our docs where people could contribute guides to setting up Mathesar on different infrastructure. Let me know if that's something you'd be interested in contributing to!

Just a heads-up, I’m opinionated on this!

Every app has some terminology you need to learn to use it effectively, we just think that terminology should actually map to how databases work, rather than being an arbitrary abstraction. Instead of inventing our own terms, we stick to tables, records, schemas, and relationships so that users who learn Mathesar are also learning concepts that translate directly to Postgres (or relational databases in general).

Making software approachable isn’t about hiding complexity, it’s about presenting it well. The UI patterns you use determine whether a system feels intuitive, not whether the underlying mental model is simple. A well-designed interface can make even complex concepts feel natural, while a bad one can make simple tasks frustrating. Mathesar doesn’t make databases approachable by pretending tables aren’t tables, it makes them approachable by using familiar interactions, and progressively exposing functionality as you need it.

We do want to work on surveys ("forms") soon, and we're definitely thinking about bulk actions and integrations as well. Please feel free to open a feature request on https://github.com/mathesar-foundation/mathesar/issues for anything that would particularly help your use case.

Ultorg is awesome! Eirik (Ultorg's founder) and I compare notes every once in a while. :)

If you're referring to the line count being omitted here: https://github.com/mathesar-foundation/mathesar/graphs/contr..., please submit your feedback to the GitHub product team, we have no say in their decision. There are some other complaints about that decision here: https://github.com/orgs/community/discussions/135572

Well, we're a nonprofit, we don't have investors :) Also, I'm pretty sure any investor who cared about commit counts would be a terrible investor.

Yep, AGPL can run alongside proprietary services without issues, and if you host it without modifications, you don’t have to share anything. But if you modify it and make it available over a network, you have to provide the source to users.

Mathesar, however, is GPL, so you only need to share modifications if you actually distribute the software itself.

Thank you! And yeah, I understand your gripe. The tagline is meant to convey the general idea of "editing data in a table UI without a lot of clicks or keystrokes" in the fewest number in words; it does sacrifice precision (although that's why it's "spreadsheet-like" and not just "spreadsheet"). Do you have any ideas for language we could use instead?

Yeah, I understand why that would be a concern. For what it's worth, our schemas are completely isolated and never touch any other data. We use them to store our DB functions and custom data types.

The functions are what lets us reflect the latest DB state in the UI in real-time without worrying about schema migrations or adding a bunch of reflection queries to each API call (which would make the UI much less responsive). We just need them installed _somewhere_ in the database.

Our custom data types (e.g. email, URL) are just available for convenience. If you don't have any columns that use those types, then you'll never need to deal with them.

We don't have any ability to customize UIs yet, although we're certainly open to feature requests.

We do have a "Record Page" for each individual record that shows a tabular view of related records from other tables, here's a screenshot from our website: https://mathesar.org/_app/immutable/assets/step-2.CKT9S1j0.a... - you can create new linked records directly there.

As for working with multiple linked tables, while editing data, you can search through nested links easily, here's an screenshot illustrating the record selector: https://mathesar.org/_app/immutable/assets/step-3.SKu3rwM2.a...

We also have a visual query builder that can join data across tables: https://github.com/user-attachments/assets/7ff100fe-cd26-422... and https://github.com/user-attachments/assets/0df680d3-621d-466...

I hope that helps!

I think it was termites. But they built a huge spaceship.

Mathesar doesn’t cache any database state, it always reflects the live structure of the database. If you run migrations through SQLAlchemy or Django, Mathesar will just show the database as it is before and after the migration, no extra steps needed.

You can also modify the data model directly in Mathesar, but if you’re using an ORM-managed database, you’ll need to update the ORM layer yourself to reflect any schema changes. If your ORM expects strict control over the schema, it’s a good idea to configure our permissions to prevent users from making data model changes in Mathesar's UI. Otherwise, it should coexist just fine.

sixdimensional covered this pretty well, but just to reiterate, I believe DBeaver is primarily a desktop app aimed at a technical audience. Mathesar is web-based and designed to have an intuitive, collaborative, spreadsheet-like UI for non-technical users who know anything about SQL or DB concepts. Also, Mathesar has deep integration with Postgres features e.g. you can configure roles and privileges through the UI.

Never give up, never surrender!

Here's some background info on our current funding: https://mathesar.org/blog/2024/03/28/mathesar-foundation-ann...

We're working on multiple options for sustainability, both the traditional nonprofit route (major donors, individual sponsors, etc.) and also looking into revenue from hosting or services. We're committed to always being 100% open source and self-hostable no matter what.

Yep, Mathesar is GPLv3, not AGPL, so there’s no issue running it alongside proprietary services. Companies can absolutely use Mathesar as a standalone service in their stack without open-sourcing their other components. Another example of this is WordPress, which is also GPL, and has a thriving hosting ecosystem.

GPLv3 only applies if you modify and distribute Mathesar itself, it doesn’t extend to services that simply interact with it. If a company makes changes to Mathesar and distributes that modified version, then those modifications would need to be open-sourced under GPLv3. But using Mathesar as a microservice in an enterprise stack? No problem.

We’d love to see companies upstream fixes and improvements, of course!

This is one of the things we're actively considering working on soon! It's mentioned in the "What's next?" section of our beta release announcement: https://mathesar.org/blog/2025/01/29/release-0-2-0

Metabase is a BI tool focused on querying, reporting, and visualization, but it’s read-only. Mathesar is closer to Airtable, you get a spreadsheet-like UI, you can view and query data like Metabase, but you can also add and edit data or even modify the data model (if the permissions allow it). Unlike Metabase, Mathesar also lets you create a database from scratch rather than just connecting to an existing one.

Metabase adds an abstraction layer with concepts like questions, segments, and metrics, while Mathesar works directly with Postgres tables, schemas, and permissions. Mathesar is deeply integrated with Postgres, so it supports Postgres-native features like role and privilege based access control, which aren’t possible in products designed for multiple database backends.

I hope that helps!

Thanks! We do not have a SQL editor in the UI yet, but it's one of the things we're actively considering working on soon, it's mentioned in the "What's next?" section of our beta release announcement: https://mathesar.org/blog/2025/01/29/release-0-2-0

I'm not sure if this would fit your use case, but you can also use a separate SQL editor alongside Mathesar, we always reflect the latest state of your DB.

Mathesar project lead here, it's a nice surprise to see this on the front page! I'm happy to answer questions if anyone has any.

I also went through the exact same thought process, then I thought I could at least share my ACE score, and yeah, no. I noticed that the OP is using a throwaway account as well.

I assume by zip code.

I'll throw in https://github.com/mathesar-foundation/mathesar (disclaimer: I work on it).

If anyone wants to read the foreword, you should be able to if you click on "read sample" on https://www.amazon.com.au/Word-World-Forest-Ursula-Guin/dp/1....

My copy of the book has a foreword by Le Guin where she said something along the lines of being very emotional about current day politics (current at the time of writing) when she wrote the book, and that she was not trying to be nuanced.

That set my expectations for the book and I was able to enjoy it for what it was. It probably also helped that I knew that writing style wasn't typical for her given that I'd read at least seven other books by her before The Word for World is Forest.