[HN Gopher] Mathesar - an intutive spreadsheet-like interface to...
       ___________________________________________________________________
        
       Mathesar - an intutive spreadsheet-like interface to Postgres data
        
       Author : gjvc
       Score  : 211 points
       Date   : 2025-01-30 00:31 UTC (22 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | neoecos wrote:
       | This looks exactly like something my finance team asked me for
       | yesterday. Definitely will take a look. In my startup (a fintech)
       | we tried to keep all the information about money in the DB, and
       | have the finance team use that to compare with actual bank
       | information
        
       | gjvc wrote:
       | see also https://mathesar.org/ for screenshots
        
       | kgodey wrote:
       | 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.
        
         | amarant wrote:
         | How do you differentiate from, say, dbeaver, or any similar
         | database management software? What's the main reason to get
         | Mathesar instead of DBeaver?
        
           | sixdimensional wrote:
           | 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.
           | 
           | All interesting choices, looks cool!
        
             | Imustaskforhelp wrote:
             | Yes this definitely feels like MS access but open source
             | and based on postgres which is awesome!
        
           | thomasfromcdnjs wrote:
           | I'd be more curious about how it differs to Metabase?
        
             | kgodey wrote:
             | 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!
        
           | kgodey wrote:
           | 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.
        
             | zokier wrote:
             | What about tools like LibreOffice Base and KDEs Kexi?
        
               | anonym29 wrote:
               | 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.
        
             | irq-1 wrote:
             | > ... 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.)
        
         | potamic wrote:
         | Your website says you're a non-profit. Do you have any
         | monetization plans down the line, otherwise how are you
         | planning to maintain funding?
        
           | kgodey wrote:
           | 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.
        
         | Galatians4_16 wrote:
         | Ah. Thermians, from the Klaatu Nebula. Or was it Dalmations?
        
           | kgodey wrote:
           | I think it was termites. But they built a huge spaceship.
        
         | igor47 wrote:
         | 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)
        
           | kgodey wrote:
           | 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/_a
           | pp/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!
        
             | savolai wrote:
             | This would probably work for us but being able to
             | 
             | * 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.
        
           | j45 wrote:
           | I'll be trying this out for my needs, it seems closer to what
           | I've wanted.
           | 
           | Along the way other nice projects for slightly different but
           | also overlapping use cases include teable.io, budibase and
           | supabase among others.
        
         | boruto wrote:
         | I tried to propose this to our team, But the option that it
         | installs some schemas was a blocker. I do like using this tool
         | on local pgdump.
        
           | kgodey wrote:
           | 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.
        
         | maxloh wrote:
         | Any comments on Outerbase?
         | 
         | That poped up on HN too a few weeks ago.
        
           | zackdotcat wrote:
           | 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.
           | 
           | 2. Mathesar is entirely free and self-hosted.
        
       | mrorangewebsite wrote:
       | I'll try to install this sometime. The permissions bit looks
       | nice. It's nice to see a project that isn't reinventing the
       | wheel. Is there a SQL editor? I don't see anything about one in
       | the docs but that would be a bit of a dealbreaker for me.
        
         | kgodey wrote:
         | 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.
        
       | sirjaz wrote:
       | It would be great if this was a desktop app. That way I wouldn't
       | need to spin up another server
        
         | sixdimensional wrote:
         | There is a docker image at least. Would be cool as a standalone
         | tool though, I kind of agree.
        
         | somat wrote:
         | At least it's not an electron app.
         | 
         | 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.
        
       | bitwize wrote:
       | I love the name. A reference to the head Thermian from Galaxy
       | Quest.
        
         | kgodey wrote:
         | Never give up, never surrender!
        
           | Galatians4_16 wrote:
           | By Grabthar's Hammer, you shall be avenged!
        
       | insert_nick wrote:
       | Any chance it's going to support PostGIS, with a map to show
       | geometry data?
        
         | kgodey wrote:
         | 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
        
       | akrauss wrote:
       | I can see this being very useful for many admin interfaces where
       | some basic data must be managed by domain experts and UX and is
       | not a priority. Many enterprise applications have such parts.
       | 
       | 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.
        
         | kgodey wrote:
         | 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!
        
           | red_trumpet wrote:
           | Does AGPL have trouble running alongside proprietary
           | services? I always thought AGPL means that if you host the
           | software, you have to make any changes you did available to
           | the users. So if you host it without changes, there is no
           | problem?
        
             | kgodey wrote:
             | 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.
        
               | yandie wrote:
               | When I was at a big tech, the interpretation by their
               | lawyers was that by running AGPL, we will have to open
               | source everything in the network to users. The problem is
               | in the definition of "Modification" - Per [AGPL](https://
               | www.gnu.org/licenses/agpl-3.0.en.html#:~:text=To%20%...):
               | 
               | > "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.
        
       | SteveVeilStream wrote:
       | Love this. Will be trying it out.
        
       | darkteflon wrote:
       | Does / how does this handle migrations? Is it happy co-existing
       | with an SQLAlchemy or Django ORM- managed PG instance?
        
         | kgodey wrote:
         | 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.
        
       | dugite-code wrote:
       | It's a great looking interface but I have the same gripe with the
       | tagline that I have with Grist's. It's really not spreadsheet
       | like is it? You just don't have the row and column manipulation
       | possibilites that defines a spreadsheet vs a table.
        
         | kgodey wrote:
         | 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?
        
       | gcanyon wrote:
       | Does anyone know if there's something similar for mysql?
        
         | breadwinner wrote:
         | Yes, you can try Visual DB: https://visualdb.com
        
       | peppertree wrote:
       | Mathesar repo is heavily optimized for commit count. Large number
       | of commits are spelling/padding changes. This should set off
       | alarm bells for anything looking to use this.
        
         | sophacles wrote:
         | Why is lots of little commits a problem?
         | 
         | 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?
        
         | mpalmer wrote:
         | Read the code, not tea leaves
        
           | peppertree wrote:
           | Project activity is indicative of whether it will be
           | supported in the long run. The fact that Mathesar's admin hid
           | the line change count under insights, and padded the commits
           | looks like a feeble attempt to impress investors.
        
             | kgodey wrote:
             | 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.
        
               | peppertree wrote:
               | Let's be transparent and unhide the line change count
               | under your insights tab.
        
         | zackdotcat wrote:
         | These are bizarre claims. Go look at the commits. It's quite
         | reasonable for a serious software project to have a feature
         | freeze and lots of documentation-related optimizations before a
         | release.
         | 
         | If you go back about a week, all of the commits relate to
         | adding and modifying app functionality.
        
       ___________________________________________________________________
       (page generated 2025-01-30 23:01 UTC)