Mathesar – an intutive spreadsheet-like interface to Postgres data
github.com
github.com
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!
* do unit conversions by a multiplier - showing converted values in ui and converting on read and store
* hiding some (empty and irrelevant for specific situation) fields conditionally on values of other fields
would make this a much better fit.
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
Along the way other nice projects for slightly different but also overlapping use cases include teable.io, budibase and supabase among others.
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 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.
All interesting choices, looks cool!
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.
This could not have been better said.
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!
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.
There should be any notable performance decline, since the Python backend is just an API proxy towards PostgresSQL database servers.
That poped up on HN too a few weeks ago.
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.
2. Mathesar is entirely free and self-hosted.
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.
3. This is true.
4. Outerbase is open-source with more and more features heading into our core offering there. https://github.com/outerbase/studio
1. Ability to view relationships inline. It's shocking that most GUIs for databases don't do this. I don't want to see a foreign ID, I want to see a sample of the related row. Glad this tool gets it.
2. Filtering and grouping and views. Not simple SQL WHEREs but easy filters. And grouping by header. This is what made Airtable king. Glad to see it is covered here.
3. AI-generated queries and reports. Sorry, but it's 2025 and you release a product without AI? It's now trivial to generate correct SQL queries and graphs based on natural language. Why doesn't any mainstream tool do this? See for example: https://www.youtube.com/watch?v=ooWaPVvljlU
Having all of these 3 core features together in the same tool would be the holy grail for me in database management.
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.
Just wondering what's the main different between Mathesar with NocoDB and Baserow?
Is Mathesar planning to become Airtable open source alternative as well?
[1] Just use Postgres for everything (430 comments):
https://news.ycombinator.com/item?id=33934139
[2] Just Use Postgres!
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.
I wonder what the GPLv3 licensing means for such scenarios: Could people run Mathesar one microservice in an ensemble with proprietary services? Companies who don‘t want to open source their whole product might still be willing to upstream their fixes and improvements to the Mathesar component.
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!
Mathesar, however, is GPL, so you only need to share modifications if you actually distribute the software itself.
> "The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities."
This can be interpreted as even modifying any configuration to allow the software to run on your own infrastructure. Obviously this is a very aggressive interpretation but the lawyers didn't want us to test this phrase in court so all AGPL software had a blanket ban.
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.
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.
No answers like "you can use it for anything" or "it's up to you" or "just like Airtable" please.
I'm interested in real world, specific use cases, so readers can position this app and figure out if it has any value for them.
Only spaceballs was a better scifi parody movie and that is hard to beat.
Every single time I see an electron app, I wish there was a way to deelectronify it and just run it as a server.
Mainly I am bitter because I run an openbsd desktop and would have a pretty good chance at getting it to run if it were a normal web app. cross platform my elbow.
If you go back about a week, all of the commits relate to adding and modifying app functionality.
How is that evidence of optimizing for commit count as opposed to lots of people submitting PRs to cover low hanging fruit?
What does optimizing for commit count achieve for anyone? In what context does "lots of commits" gain someone enough value to optimize for it?