How does this compare to retool? I've been using that to build UIs directly on top of
Postgres, and it's been nice to be able to design the screens a little; eg inserting new rows linked to a currently selected row by primary key. Curious if you're targeting primarily a spreadsheet-like view, or if the interface can be customized. How does the spreadsheet view work across multiple linked table? Can you present the tabular info in non tabular ways (e.g. a row details or editor view)
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.
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.
I'm not related to the author or developers, but this appears almost like an Airtable-like (or Nocodb) UI on top of postgres, so it's really quite a different experience than a full database manager tool/IDE like DBeaver or DataGrip.
I love it personally and it looks pretty good so far. Also, amazing that the team started it as an open source project under a 501c3 nonprofit as well.
Having a more "spreadsheet" (or I would say, MS Access-like) UI is quite cool for certain use cases (e.g. low/no-code but backed by the full power of regular old Postgres). Can allow pretty agile development, although - it can get out of control if not managed with care... but nice to see the access controls/permissions there to help a bit.
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.
> ... spreadsheet-like UI for non-technical users who know anything about SQL or DB concepts.
All the language is DB: it's tables not spreadsheets, records not rows, etc... It also doesn't hide things like 'schema' button or metadata like table description.
Maybe this project could do things like integrations with web services, easy actions on groups (like paste a list of ids and do something to all those records), and publicly available web pages (surveys, donations, pretty event pages.)
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.
> 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.
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.
Far too technical for the target audience, who has never heard of a "linux" and doesn't care about cost, software freedom, the petite tyranny happily imposed by corporations, etc, they just want it to "just work" on their smartphone browser.
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.
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 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!
I'm not OP but from my experience with both tools there are some main differences within the products:
1. Mathesar includes a lot of cool UI elements for CRUD operations on tables, schemas, and columns. Outerbase doesn't have any UI for this, but only a SQL editor.
2. Mathesar has a lot of support for "relationships" (more accurately described as references in Postgres, but I digress) that Outerbase does not. For example, if you're inserting a foreign key column into Outerbase you have to manually type the value of the column you're referencing. In Mathesar, you'll see a dropdown of all the "related" rows and be able to search through their columns to find the record you need.
3. Mathesar is postgres-exclusive, while Outerbase works with many other DB providers.
And more in terms of governance and usage:
1. Outerbase is paid, with a very restrictive free tier. The option to self host is only available to enterprise customers.
Hi I'm one of the founders of Outerbase, just want to clarify a few things, seems like you might have some wrong information on Outerbase.
Big fan of Mathesar by the way!
1. We have a incredibly powerful CRUD editor on our table, in fact you can drag and drop and select multiple columns & rows, I haven't seen many other DB editors support this.
2. We allow you to pick foreign key constraints from a dropdown as well.
