bram2w

Hey HN, founder of Baserow here. Since our success on Hacker News a couple of years ago, we've grown from a no-code database into a full-stack no-code platform. It's now possible to create databases, applications, automations, and dashboards via the no-code interface and with Kuma, our AI-assistant.

We believe in a platform with a conversational agent that can build complete software solutions, like Lovable, while also having a flexible no-code interface to make changes manually. This gives the builder the opportunity to get started quickly, have insights in what happens under the hood, and have the ability to make changes, without writing code.

Because of our open background, full self-hosting capability, API-first approach, integrations, and enterprise grade security, it makes modern no-code tools accessible to industries that were previously forced to work with expensive off the shelf solution with long implementation time.

Today, we're launching Baserow 2.0 that introduces our AI-assistant Kuma, automations builder, improved AI field, and many more features. We're looking forward to your feedback.

You can do this soon with Baserow. We're currently working on view-level permissions, where you can give a user access to a specific view. That user will then only have access to the filtered rows and visible fields.

When I started working on Baserow (this seems similar based on the roadmap), a couple of years ago, I thought it would be a big challenge to quickly render a million rows in the browser. Introducing a system that fetches a page of rows based on the scroll offset, and with a small debounce did the trick. We only had a couple of field types, and it was all incredibly fast

The thing that make performance complicated for a no-code database is when you have 30 interconnected tables, some tables with 200 fields, containing many formulas or other computed fields like lookups or rollups. Updating a single cell, can result in thousands of other rows that must be updated across different tables. If there are 30 users making constant changes, locking PostgreSQL rows under the hood while the formulas are recalculated, and then a couple of n8n workflows making a many API requests to those tables, that's when things get interesting. Especially in combination with features like webhooks, real-time updates, 100+ filters, grouping, 26 field types, date dependencies, aggregations, importing/exporting whole databases.

When implementing a new feature, I've heard users say that's not complicated because it's just adding a checkbox. Making to run it at scale and keeping things performant is what's making it complicated.

Founder of Baserow here. We're actively working on improving that. We recently introduced the data sync feature that allows you to sync data from various sources into a Baserow table. One of the integrations is a PostgreSQL table, and we have MySQL and SQLite on the planning as well. Currently, it's a one-way sync, but we're planning on making it a two-way sync in this quarter.