Plato is an Airtable-like interface for your Postgres or MySQL database. It's an admin panel for devs and non-devs alike to manage your DB. We see teams use Plato for customer support, customer success, ops, etc..
We built Plato because we think more people should be able to build and extend internal tools. We thought it was strange that even though low-code is supposed to democratize development, all of the low-code internal tool builders are marketed to engineers! Airtable is a familiar UI that fits the relational model well, so we've been inspired by their work. Even the engineers on our team use Plato quite a bit, since it's often easier than spinning up a SQL prompt.
Some features:
- Postgres and MySQL support
- Visual query controls (sorts, filters, hiding columns). No SQL.
- Joins by "expanding" foreign keys
- Virtual columns for tracking new data
- Auto-generated backlinks for one-to-many relationships
- Read-only locking for individual tables
- Virtual tables for sharing new views with your team
Plato today works on databases with a public IP (just whitelist our IP to connect), but we're soon rolling out an on-prem version. We can also set up an SSH tunnel for you if you contact us at team@plato.io.
We'd love to hear your feedback! Thanks.
- Michael
Do you have any additional “killer feature(s)” that might convince me to switch?
The killer feature for many users is the ability to track new data with *virtual columns*, which stay in Plato and never touch your backend DB. It lets you extend schema for new operations without having to run a DB migration. They're great for support agents or other operators to take notes, track new customer requirements, etc..
I see at the current state there is a massive difference between us and the initial launch of Plato.
We do support multiple databases and there are backlinks available with actual value in a spreadsheet cell (I see that isnt supported in Plato's links). By reading about virtual columns I felt its like a formula column but its not (between I don't see formula isn't supported yet in Plato). Only one of our user had the virtual column request before.
Mainly I see Plato does not YET support automatic Rest APIs for the databases, webhooks, grid view, gallery view, form view, webhooks, upload csv/json/excel, formulas, SQLite, SQL server, docker, executables, open-source and so many other features. Having said that Im sure these will be looked into in coming years.
Really happy to see simple and powerful tools in this space were lacking and we are all trying to fill the big void here.
A huge strength of NocoDB is that it is run as just another service accessible your DB that you own.
I can see Virtual Columns being interesting for reporting-type purposes. The mentioned use case of “notations” on data owned by someone else is also interesting. But again - do I really want someone else hosting my data? I don’t know.
Is the target here then basically shadow IT adding onto other people’s data sources that they can’t get the devs to change directly?
- Virtual columns that track new data w/o modifying the DB (Great for ops)
- Virtual tables for saving new table views and hiding their implementation details
- Inline edits (Django requires click through to forms)
- More user-friendly queries (Subjective, but I remember filters in Django being tedious)
There's also some rough edges in Django Admin, like IIRC for foreign key select inputs they have to load every value into the frontend, which grinds to a halt for anything other than small databases.
I'd love to have you try it out and compare. Shoot us an email!
FWIW, virtual columns and tables are pretty easy in Django. AJAX-ify the forms seems to be possible but the packages tend to be pretty out of date.
Obviously you product has value for non Django teams, but tbh it's not clear to me this project is a win over django-admin for me (someone who reaches for that as my first tool to solve this problem). And some of the rough edges are not that big of an issue for me personally, not enough to add unknown risks w/ a new technology.
It does look great, however - hopefully this feedback is useful because I definitely don't mean to crap on your service.
It sounds like your friends didn't talk to the accountants to ask them what they wanted.
At that particular company, the accountants would often come across new tax form data they'd need to track. Waiting on eng to migrate the DB was too slow.
We use Metabase at our company (created and managed by a non developer). Can you share some reasons for us to switch to Plato?
Startups use us to diagnose support issues, track new user data for ops, extend user trials, manually update ML training sets, etc..
You want to scope access via a BI tool to the business person. That is data archtecture 101. And when the access is scoped a BI tool like metabase or superset services a better purpose than this.
The first normal form (1NF) requires that each column in a table must hold atomic (indivisible) values, meaning that each value in the column must be unique and cannot contain multiple pieces of data.
I know Airtable has it, but this is an RDBMS focused product, and it seems to encourage poor habits.
I think it's a smart pitch because a large chunk of that target audience has at least a basic idea of what both of those things are, and it'll hit pretty close to home for those people who've experienced the pain points of both of those options doing a thing very well, and a thing not well at all (which the other does well)
Perhaps they'll target other groups in the future, but in the meantime both of those things have a wealth of information for those looking to learn also.
No image support yet.
One advantage is that Plato is SaaS so you don't have to run it yourself. NocoDB's cloud offering is still in private beta.
Others:
- Multi database support
- Virtual columns for tracking new data without modifying the DB
- Backlinks for one-to-many relationships!
But the biggest difference is probably the roadmap outlined in our blog post. We aim to be a general purpose sandbox for all kinds of internal tools. The database admin is just the first step.
- How connections between multiple tables are represented and managed
- How derived data is described (queries, workflows etc.)
Typically such tools are aimed at simplifying data connections but normally they end up with some kind of join-like approach which requires high expertise and is error prone. So users have to deal with something they wanted to get rid of when they buy the tool. Plato is not an exception: "No SQL needed". Yet, I could not find any information on how exactly it manages connections between tables and how the unified "virtual table" is defined.
The second question is about how we can derive new data from existing data. Ideally, users would like to have something very similar to Excel because spreadsheets are indeed extremely intuitive: we define new cells as functions of other cells (which in turn might be functions of other cells). In Plato I found "virtual columns" which should be rather useful. This is somewhat similar to the column-oriented approach implemented in Prosto [0]. Yet, what is really non-trivial is how to define (derived) columns by combining data from multiple tables.
In general, the tool looks very promising and I hope that additional features and additional information will make it really popular.
[0] https://github.com/asavinov/prosto Prosto is a data processing toolkit radically changing how data is processed by heavily relying on functions and operations with functions - an alternative to map-reduce and join-groupby
Pkey/Fkey joins are supported in Plato by "expanding" foreign keys. You can log in, connect our sample DB, and play around with how it works. It's pretty easy. We're soon adding support for generic joins as well.
And, yes! We take a more structured, column-oriented approach than Excel. Much like Airtable. Though we are introducing an Excel-like formula language for defining derived values. It will compile to SQL on the backend, but not expose that to the user.
no pg_hba.conf entry for host
As for security, the short of it is that you whitelist our IP, and your DB will need a public address we can connect to. It's similar to how e.g. cloud Retool works. We're shipping on-prem soon.
Here's our full security docs: https://plato-app.notion.site/Security-Overview-6e38fdc4daf0...
I suspect that the space really needs to target specific use cases and nail those experiences.
Good luck!
Congrats on the launch!!
I noticed you are using Notion for your docs so i tried creating a website using Notaku [0]
Here is how it looks: https://plato-preview.notaku.site/
