Baserow é uma plataforma no-code de banco de dados construída sobre uma arquitetura sofisticada de geração dinâmica de modelos Django, sistema de plugins baseado em registries e colaboração em tempo real via WebSockets. O projeto combina decisões técnicas pragmáticas (Django + PostgreSQL + Nuxt.js) com uma filosofia radical de transparência open-source, criando um produto que compete diretamente com Airtable enquanto oferece auto-hospedagem ilimitada e extensibilidade completa. Com crescimento de 300% em ARR, ~100 mil usuários e ciclos de release de 4 semanas que entregaram 180+ features em 2024, Baserow demonstra que é possível construir um negócio sustentável sem comprometer os princípios open-source.
A principal inovação arquitetural está na geração dinâmica de modelos Django em tempo de execução — quando usuários não-técnicos criam tabelas através da interface, Baserow usa a função type() do Python para gerar classes Django dinamicamente e o schema_editor para criar tabelas PostgreSQL reais. Isso permite que cada tabela criada pelo usuário seja uma tabela PostgreSQL verdadeira (não JSON blobs), mantendo todo o poder do ORM Django para prevenção de SQL injection e otimizações de query.
O coração técnico do Baserow está em como ele resolve um problema fundamental: como permitir que usuários não-técnicos criem schemas de banco de dados arbitrários mantendo a robustez e segurança de um sistema enterprise-grade?
A estrutura de dados segue esta hierarquia: Workspace → Application → Database → Table → Field/View/Row. No backend (backend/src/baserow/), isso se traduz em:
Models core (baserow.core.models): Workspace (container multi-usuário com controle de acesso), Application (conceito abstrato extensível via plugins)
Models de database (baserow.contrib.database): Table (metadados de tabelas criadas por usuários), Field (tipos polimórficos — TextField, NumberField, DateField, etc estendendo Field base), View (Grid, Kanban, Calendar, Gallery definindo visualizações), Row (armazenado em tabelas dinamicamente geradas)
O verdadeiro diferencial está no Table model. Cada instância de Table tem um método get_model() que gera dinamicamente uma classe Django Model em runtime:
table = Table.objects.get(pk=10)
# Gera modelo dinamicamente baseado nos fields
model = table.get_model(attribute_names=True)
# Agora pode usar ORM normal
for row in model.objects.all():
print(row.name, row.price)Internamente, isso usa type() do Python para criar classes programaticamente:
Project = type(
"Project",
(models.Model,),
{
"name": models.CharField(max_length=255),
"Meta": type("Meta", (), {"app_label": "database"}),
"__module__": "database.models"
}
)Quando schemas mudam (novo field adicionado), Baserow usa o schema_editor do Django diretamente:
with connection.schema_editor() as schema_editor:
schema_editor.add_field(TableModel, field_instance)Baserow tem 20+ tipos de field implementados através de herança polimórfica e registry pattern. Cada field type é uma classe que implementa a interface FieldType:
class IntegerFieldType(FieldType):
type = 'integer' # Identificador único
model_class = IntegerField # Model Django
def get_model_field(self, instance, **kwargs):
return models.IntegerField(null=True, blank=True)
def prepare_value_for_db(self, instance, value):
# Validação customizada
if value and not instance.integer_negative and value < 0:
raise ValidationError('Cannot be negative')
return value
def get_serializer_field(self, instance, **kwargs):
return serializers.IntegerField(required=False)No banco de dados PostgreSQL, os fields são armazenados como colunas com convenção field_{id}. Por exemplo, se você cria um field "Nome do Cliente" que recebe ID 42, a coluna PostgreSQL será field_42. Isso permite adicionar/remover fields dinamicamente sem conflitos de nomeação.
O sistema de plugins é baseado em singleton registries que permitem extensibilidade em runtime. Os principais registries são:
Backend: field_type_registry, view_type_registry, application_type_registry, field_converter_registry, action_type_registry
Frontend (JavaScript/Vue.js): Registries paralelos com mesma estrutura
Para criar um plugin, você:
- Cria Django app com models customizados
- Implementa classes que estendem tipos base (FieldType, ViewType, etc)
- Registra no
ready()do AppConfig:
class PluginConfig(AppConfig):
def ready(self):
from .field_types import CustomFieldType
field_type_registry.register(CustomFieldType())Plugins podem instalar extensões PostgreSQL (como PostGIS para campos geográficos), adicionar funções de fórmula customizadas, criar novos tipos de view, e até modificar páginas e componentes do frontend.
A arquitetura de real-time usa Django Channels com um serviço ASGI separado. A conexão WebSocket é autenticada via JWT:
wss://api.baserow.io/ws/core/?jwt_token=YOUR_JWT_TOKEN
Sistema de page subscription evita sobrecarga de mensagens — usuários se inscrevem explicitamente em páginas específicas (table, row) para receber atualizações:
socket.send(JSON.stringify({
"page": "table",
"table_id": 1
}))Evento types incluem: rows_created, rows_updated, rows_deleted, field_created, field_updated, field_deleted, view_updated, etc.
Echo prevention: Quando você faz uma mudança via API, inclui seu WebSocketId no header para não receber sua própria mudança de volta.
A infraestrutura usa múltiplos serviços Docker: backend-wsgi (API REST Django), backend-asgi (WebSocket API), celery-worker (tarefas async de alta prioridade), celery-export (tarefas de baixa prioridade), com Redis como message broker e cache, e PostgreSQL para dados.
A decisão por Django foi explicitamente estratégica. A equipe escolheu frameworks populares para reduzir a barreira de entrada para criação de plugins. Django oferece:
Funcionalidade completa out-of-the-box: ORM poderoso, sistema de autenticação, admin interface, migrations, proteção contra SQL injection/XSS/CSRF automáticas
Django Channels: Suporte nativo a WebSockets, crítico para colaboração em tempo real
Arquitetura de apps reutilizáveis: Estrutura modular perfeita para o sistema de plugins do Baserow
Provado em escala: Instagram roda em Django, demonstrando viabilidade em produção massiva
ORM com geração dinâmica de modelos: Capacidade única de criar models em runtime via type() e schema_editor
A citação oficial: "No coração do backend rodamos Django. Escolhemos um framework popular para reduzir a barreira de criar plugins. Também buscávamos algo batteries-included, simples e comprovado. Django foi a escolha óbvia."
Baserow usa exclusivamente PostgreSQL 11+ (recomendando 15+). Não há suporte para MySQL/MariaDB e nunca haverá — a equipe rejeitou explicitamente essas requests da comunidade.
Razões técnicas:
Suporte a schema dinâmico: Django schema_editor funciona perfeitamente para criar/modificar tabelas em runtime
JSONB nativo: Armazenamento eficiente de metadados e configurações
Variedade de índices: B-tree, GIN, GiST, BRIN para diferentes casos de uso
Conformidade ACID: Garantias de integridade de dados
Extensibilidade: PostGIS para geolocalização, plpgsql para fórmulas customizadas
Cada tabela = tabela PostgreSQL real: Decisão técnica fundamental — permite otimização SQL direta, índices em fields específicos, e consultas complexas eficientes
A decisão de não suportar outros bancos é filosófica e prática: "Suportar outras engines requereria recursos de engenharia que preferimos gastar em novas features". Isso exemplifica a disciplina da equipe em dizer "não" para manter foco.
O frontend usa Nuxt.js 2 (migrando para v3) com Vue.js 2 (migrando para v3). A escolha foi baseada em:
Simplicidade: Vue descrito como "full-featured sem complexidade desnecessária"
Experiência interna: Time já familiarizado com Vue
Nuxt.js específico:
- Server-side rendering (SSR) out of the box
- Code splitting automático
- Estrutura de projeto modular perfeita para plugins
- Hot-reloading para desenvolvimento rápido
Alternativas consideradas: React e Angular foram avaliados, mas Vue venceu por simplicidade e produtividade.
Baserow usa puramente REST API via Django REST Framework. Não há GraphQL implementado ou planejado.
Arquitetura Handler-Based: A decisão mais importante da API é o padrão de separação entre views e handlers:
API Views (REST shell) → Handlers (business logic) → Models (data layer)
Citação dos fundadores: "As views da API são na verdade um shell REST em torno desses handlers que fazem o trabalho real. A razão de fazermos assim é que se quisermos implementar uma WebSocket API, SOAP API ou qualquer outra API, podemos construir em torno dos mesmos handlers. Assim nunca precisamos escrever código duas vezes."
Benefícios estratégicos:
- Mesma lógica de negócio serve REST, WebSocket, CLI, futuras APIs
- Testabilidade: handlers podem ser testados sem camada HTTP
- Manutenibilidade: clara separação entre protocolo e lógica
Documentação automática: Usa DRF Spectacular para gerar OpenAPI specification. Cada database do Baserow gera sua própria documentação de API automaticamente refletindo seu schema exato.
Por que não GraphQL?: Nunca mencionado nos docs, sugerindo que REST foi escolha óbvia desde o início. Razões inferidas: ecossistema Django, simplicidade para plugin developers, caching HTTP mais fácil, DRF browsable API para desenvolvimento, menor curva de aprendizado.
O sistema de permissões é baseado em permission manager chain com conceitos:
Actor (quem age: User, APIToken, AnonymousUser), Operation (ação: database.create_table, database_table.create_row), Context (objeto: Table, Database, Workspace)
Requests de permissão fluem por managers ordenados: CorePermissionManager → StaffOnlyPermissionManager → BasicPermissionManager → custom managers
RBAC hierárquico (Advanced/Enterprise): Admin → Builder → Editor → Commenter → Viewer → No Access → No Role
Regras de hierarquia: Permissão de Table sobrescreve Database, Database sobrescreve Workspace, usuário individual sobrescreve team, atribuições explícitas sempre precedem.
Checking de permissões no backend:
CoreHandler().check_permission(
actor=request.user,
operation=CreateRowDatabaseTable.type,
context=table,
workspace=workspace
)Frontend matching:
this.$hasPermission("database.create_table", database, workspace.id)Caching de modelos Django com Redis: Ao gerar models dinamicamente, Baserow cacheia os atributos de fields em Redis. Isso transforma operações de milissegundos em microssegundos para tabelas com 100+ fields.
SQL query caching (desde 1.17.2): Usa django-cachalot para cachear resultados SQL. Configurável em 3 modos:
# Conservador (padrão)
BASEROW_CACHALOT_ENABLED=true
# Agressivo (todos queries)
BASEROW_CACHALOT_MODE=full
# Excluir tabelas específicas
BASEROW_CACHALOT_UNCACHABLE_TABLES=database_table_147157Performance impact: "Aumento massivo de performance" para tabelas atualizadas <50x/minuto. Para tabelas de alta rotatividade (>50 updates/min), degradação de performance — por isso é opt-in desde 1.17.2.
Field indexes (1.34+): Usuários podem ativar índices por field no editor. Speedup de até 10x em filtering — "acelera queries de filtro em tabelas grandes em até 80%".
Arquitetura stateless: JWT authentication (sem sessões server-side), Redis para estado compartilhado, escalabilidade horizontal via Kubernetes.
Infraestrutura production (SaaS na Digital Ocean): Kubernetes com Ansible + Packer, containers separados por serviço (backend-wsgi, backend-asgi, celery-worker, celery-export, PostgreSQL, Redis, Caddy reverse proxy).
vs Airtable:
- Open-source MIT License: Licença mais permissiva, permite uso comercial sem restrições ou vendor lock-in
- Sem limites de rows/storage: Auto-hospedagem oferece unlimited vs 500k records no enterprise do Airtable
- Auto-hospedagem: Deploy on-premise para GDPR, HIPAA, SOC 2 — Airtable é cloud-only
- Performance em escala: Construído para datasets massivos sem os slowdowns que afetam Airtable
- API superior: Arquitetura API-first torna cada feature acessível via API, mais comprehensive que a "limiting API" do Airtable
- Sistema de plugins: Backend + frontend plugins vs apenas frontend extensions do Airtable
- Preço: Premium $10/usuário/mês vs Team $20/usuário/mês no Airtable
vs NocoDB:
- Foco em UX: Ferramenta turn-key para não-técnicos vs NocoDB requer conhecimento SQL
- Interface intuitiva: Consistentemente elogiada vs interface técnica do NocoDB
- Plataforma completa: Inclui Application Builder, automation engine, dashboards, controles de segurança avançados
- Licenciamento: MIT vs AGPL-3.0 do NocoDB (copyleft restritivo para empresas)
- Performance e estabilidade: Usuários reportam que NocoDB sofre crashes e timeouts com datasets grandes
- Suporte da comunidade: Time mais responsivo e desenvolvimento ativo
Métrica chave: Auto-hospedagem remove TODOS os limites — unlimited rows, storage, API calls.
Interface spreadsheet-familiar: Design deliberadamente mantém familiaridade com Excel/Sheets para reduzir curva de aprendizado, mas adiciona poder de banco de dados relacional.
Sistema de views excelente: Grid (tabela tradicional), Kanban (board), Calendar, Gallery, Form, Timeline, Survey. Settings específicos por view — largura de coluna, filtros, sorts isolados (mudança na View A não afeta View B).
20+ tipos de field: Text, long text, number, boolean, date, URL, email, file, single/multiple select, link row (foreign key), formula, lookup, rollup, count, collaborators, duration, button formulas, rating, password, AI (OpenAI/Anthropic/Mistral).
Field indexes opcionais: Ativáveis no editor de field, entregam 10x faster filtering em queries frequentes. Trade-off consciente entre velocidade de read e write overhead.
Footer aggregations: Sum, average, count calculations em footers de coluna com setup de 2 cliques.
Real-time collaboration: WebSocket-powered live updates mostram mudanças instantaneamente sem refresh.
O Application Builder é uma feature que nenhum competidor direto oferece. Permite criar aplicações web completas sem código:
Casos de uso: Internal tools, portais públicos, client portals, dashboards, resource directories, landing pages, websites
Componentes: Buttons, forms, tables, images, text, headings, links, file inputs, ratings
Data binding: Conectar elementos a data sources com filtering e sorting
Events & Actions: Click handlers, form submissions, data mutations (create/update rows), navigate pages, open URLs
Custom code (1.34+): Injeção de CSS/JS para styling avançado e interactividade
Publishing: Free Baserow subdomain ou custom domain
Status: Saiu de beta pública em late 2024, ativamente desenvolvido. Combina database + frontend builder em plataforma integrada.
Princípio core: "Baserow é construído como uma API com uma interface de usuário em cima" — toda ação é automatable via API.
Documentação auto-gerada por database: Cada database gera docs de API customizados refletindo seu schema exato. OpenAPI spec completo disponível.
Autenticação robusta: Database-scoped tokens com permissões granulares, table-level permissions (create/read/update/delete), revogação instantânea de tokens.
Developer-friendly: RESTful design, JSON data exchange, standard HTTP status codes, filtering & sorting avançados, paginação eficiente, WebSocket API para real-time.
Rate limiting transparente: 10 concurrent requests no cloud (fair use policy), unlimited em auto-hospedagem.
Feedback da comunidade: "API poderosa habilitando integração seamless e automação", "API funciona melhor comparado ao Airtable. Foi deal breaker", "Straightforward and powerful API".
Opções de deploy:
All-in-one Docker image: baserow/baserow:1.35.3 — opção mais simples, todos serviços em container único, Caddy reverse proxy com HTTPS/Let's Encrypt automático, PostgreSQL e Redis embutidos
Docker Compose: Containers separados por serviço (backend, web-frontend, PostgreSQL, Redis, Celery workers, Caddy)
Standalone images: baserow/backend e baserow/web-frontend para orquestração customizada (Kubernetes, ECS, Cloud Run)
Guias específicos por plataforma: Kubernetes (Helm charts), AWS ECS, Heroku, Render, Digital Ocean, Railway, Cloudron, Ubuntu
100+ variáveis de ambiente: Configuração extensiva, serviços externos (PostgreSQL, Redis, S3-compatible storage), reverse proxy support (Nginx, Apache, Traefik), custom domains, email SMTP, OpenTelemetry monitoring.
Features enterprise: Horizontal scaling, backup/restore via CLI tools, acesso direto ao PostgreSQL, migration tools do Airtable.
Feedback: "Fácil de auto-hospedar. Baserow fornece uma Docker image muito bem construída, que torna setup, update e manutenção uma brisa", "Uma das melhores open source projects que encontrei no último ano".
baserow/
├── backend/
│ ├── src/baserow/
│ │ ├── core/ # Core workspace/application logic
│ │ │ ├── actions/ # Undo/redo system
│ │ │ ├── handler.py # CoreHandler
│ │ │ └── registries.py # Plugin registries
│ │ ├── api/ # REST API layer
│ │ ├── ws/ # WebSocket API
│ │ └── contrib/
│ │ └── database/ # Database plugin
│ │ ├── table/ # TableHandler
│ │ ├── fields/ # Field types e FieldHandler
│ │ ├── views/ # View types e ViewHandler
│ │ ├── rows/ # RowHandler
│ │ └── webhooks/ # Webhook system
│ ├── tests/ # Pytest tests
│ └── requirements/ # Python dependencies
├── web-frontend/
│ ├── modules/
│ │ ├── core/ # Core Nuxt module
│ │ └── database/ # Database frontend
│ │ ├── fieldTypes.js # Frontend field types
│ │ └── viewTypes.js # Frontend view types
│ └── nuxt.config.js
├── docs/ # Developer documentation
└── plugin-boilerplate/ # Cookiecutter template
Organização Django apps:
baserow.core: Foundation layer — user/auth models, Workspace, Application base, action system, handler base classes, registries, trash/recovery
baserow.api: REST API exposure — application CRUD, workspace CRUD, user management, undo/redo endpoints, decorators, serializers, custom exceptions
baserow.contrib.database: Database plugin — table operations, field types, view types, row operations, webhooks, database-specific API, WebSocket handlers
1. Registry Pattern: Extensibilidade via singleton dictionaries populados em Django's ready(). Permite descoberta dinâmica de implementações por type string. Usado para: field types, view types, application types, action types, field converters.
2. Handler Pattern: Separação de concerns — API views usam handlers para business logic. Habilita múltiplos tipos de API (REST, WebSocket, CLI) compartilhando mesma lógica. Business logic testável independente da API layer.
3. Dynamic Model Generation: Runtime model creation para schemas definidos por usuários. Usa type() do Python, Django schema_editor para PostgreSQL changes.
4. Polymorphic Models: Herança de fields para diferentes data types. Base Field model com implementações específicas (TextField, NumberField, etc). Registry mapeia type strings para implementações.
5. Command Pattern: Para undo/redo (ver abaixo).
6. Observer Pattern: Webhooks implementam observability de eventos.
O sistema de undo/redo é um command pattern completo com category-based scoping e per-tab history.
Action Model Schema:
class Action(Model):
id = AutoField(primary_key=True)
user = ForeignKey(User, null=True)
session = TextField(nullable=True) # ClientSessionId
category = TextField() # 'root', 'workspace_6', 'table_10'
created_on = DateTimeField(auto_now_add=True)
type = TextField() # ActionType name
params = JSONField() # Serialized Params dataclass
undone_at = DateTimeField(nullable=True)
error = TextField(nullable=True)Interface ActionType: Toda ação undoable implementa:
class ActionType:
type = "action_name"
@dataclass
class Params:
# Parâmetros necessários para undo/redo
pass
@classmethod
def do(cls, user, **kwargs):
# 1. Perform action
# 2. Create Params instance
# 3. Call cls.register_action(user, params, category)
# 4. Return result
@classmethod
def undo(cls, user, params, action):
# Reverter ação usando params data
# NÃO registrar novas actions
@classmethod
def redo(cls, user, params, action):
# Reaplicar ação usando params dataSistema de categorias: Actions são categorizadas por contexto — root (global), workspace_{id}, application_{id}, table_{id}. Quando usuário pressiona undo, frontend envia todas categorias relevantes, backend encontra última action em qualquer dessas categorias.
ClientSessionId: UUID gerado por browser tab, enviado como HTTP header, armazena undo/redo history por tab. Previne interferência cross-tab.
Error handling: Se undo falha (ex: field deletado), error é logged em Action.error, usuário vê mensagem, action marcada como undone. Em redo, error é cleared e retry acontece.
Endpoints API: POST /api/user/undo, POST /api/user/redo (ambos retornam lista de actions undone/redone).
TableWebhook Model:
class TableWebhook(Model):
table = ForeignKey(Table)
name = CharField(max_length=255)
url = URLField()
method = CharField() # POST, GET, PUT
headers = JSONField()
events = ArrayField() # ['rows.created', 'rows.updated', etc]
active = BooleanField(default=True)
call_log = JSONField()Event types: rows.created, rows.updated, rows.deleted (batch); row.created/updated/deleted (deprecated single); view.updated, field.created/updated/deleted.
Flow de eventos:
- Usuário cria/atualiza/deleta rows
- Database operation performed
- Signal/handler triggers webhook check
- WebhookHandler.trigger_webhooks() encontra webhooks ativos com matching event
- Build JSON payload, queue async Celery task
- Celery worker faz HTTP request
- Log response em call_log
- Retry logic se failure (exponential backoff, limited retries)
Payload structure:
{
"event_type": "rows.updated",
"table_id": 123,
"items": [{"id": 456, "field_42": "new_value"}],
"old_items": [{"id": 456, "field_42": "old_value"}]
}Conditional webhooks: Filtrar por field changes específicos, usar view-based webhooks (apenas rows matching view filters), adicionar custom headers (API keys).
Limites: Cloud tem máximo de 5,000 pending calls por webhook, calls processados sequencialmente (one at a time).
Cada módulo Nuxt segue estrutura padrão:
modules/{module-name}/
├── components/ # Vue components
│ ├── common/ # Shared
│ └── specific/ # Feature-specific
├── pages/ # Route pages
├── store/ # Vuex store modules
├── {type}Types.js # Registry exports
│ ├── fieldTypes.js
│ └── viewTypes.js
└── module.js # Nuxt module entry
Component patterns: Cada field type tem FieldName.vue (display), FieldNameForm.vue (settings), FieldNameCell.vue (grid cell). Cada view type tem ViewName.vue (main), ViewNameContext.vue (context menu), ViewNameForm.vue (settings).
Store organization (Vuex): workspace.js, application.js, table.js, view.js, field.js, undoRedo.js.
Registry pattern (frontend):
// Em module.js
export default function(context) {
const { app } = context
app.$registry.register('application', new DatabaseApplicationType(context))
app.$registry.register('field', new TextFieldType(context))
app.$registry.register('view', new GridViewType(context))
}Baserow migrou recentemente de GitLab para GitHub (late 2024/early 2025) para melhorar discoverability e alcançar mais contribuidores open-source. Repositório oficial agora em https://github.com/baserow/baserow. GitLab permanece como read-only mirror.
Undo and Redo (#136): Feature long-standing e altamente requisitada. Backend-based undo/redo system com action log, todas operações CRUD em groups/databases/tables/views/fields/rows devem ser undoable, CTRL/CMD+Z shortcuts, toast notification com undo button após deletions. Complexidade substancial, impacto alto (previne perda acidental de dados).
Field Value Constraints (#647): Validação além de restrições básicas de field type. Constraints requisitados: required fields (non-null), unique values, one-to-one/one-to-many enforcement para linked fields, numeric min/max, string length limits, regex patterns, deny lists. Quote: "Almost every user would find some form of constraint useful". Já entregue parcialmente em 1.34 (unique values, validation).
Composite Primary Key (#247): Ability to create primary keys from multiple fields para funcionalidade relacional de database verdadeiro.
External Authentication/SSO (#848): Suporte para RFC3875 REMOTE_IDENT headers e OpenID Connect (JWT) para deployments enterprise requiring gateway authentication.
ALLOWED_HOSTS Configuration Issues (#873): Configuração complexa de auto-hospedagem causando muitos issues. Solução proposta: replace environment variable com dynamic admin setting no database.
Database features: Drag-and-fill functionality (estender cell values down columns como Google Sheets), create/link records on import (auto-create linked records ao importar/colar data), default field values, one-to-one relationships, advanced filtering.
User experience: Better view navigation (teams com 30+ views precisam de melhor organização), row change history (entregue 1.21), group by functionality (entregue 1.22).
Integration & automation: Native Automation Builder (prioridade #1 para 2025), webhook receivers (atualmente só envia, não recebe), more data sync integrations (expandindo além dos atuais).
Roadmap oficial mantido em baserow.io/product/roadmap com community voting.
Já entregue (2024-2025):
- Timeline View (1.28)
- Data Sync — iCal, Baserow tables, Jira, GitLab, GitHub, PostgreSQL (1.28-1.29)
- AI Field com multiple providers — OpenAI, Anthropic, Mistral (1.24, 1.29)
- Calendar View improvements
- 600% Faster Formulas através de otimização (1.27)
- Field Indexes — 10x faster filtering (1.34)
- Field Value Constraints — unique values, validation (1.34)
- Application Builder — full frontend builder
- MCP Server — AI-powered data management (1.33)
Next Big Features (2025 Roadmap):
- Automation Builder (highest priority) — native workflow automation
- Analytics Dashboard — data visualization
- More AI Features
- Field Level Permissions — granular access control
- Advanced Permissions for Application Builder
- Multi-page Container for Application Builder
- Airtable Import Improvements
- Additional Data Sync Integrations — Zendesk, Salesforce, HubSpot planned
Self-hosting challenges: Configuration complexity (ALLOWED_HOSTS, BASEROW_PUBLIC_URL), performance at scale (2-3 second delays com large datasets/complex formulas/extensive lookups), WebSocket connection issues em certain network configs, container permission issues em várias plataformas.
Feature maturity: UI/UX não tão polished quanto Airtable ("Not as polished as Airtable or Rows — product stable but not fully mature"), missing native automations (requer third-party tools como n8n/Zapier/Make), limited external database support (cannot connect to existing databases like NocoDB — closed as "not planned").
Cloud vs self-hosted differences: Cloud rate limits (10 concurrent requests max), cloud row limits (Free 3k, Premium 10k, Advanced 100k), self-hosted unlimited rows/storage/API requests (major advantage).
Mission 2025: "To become the open platform to create scalable databases, applications, and workflows without coding"
Focus areas 2025:
- Automation Builder para reduzir dependência de third-party tools
- Full-stack no-code platform — Database + Application + Automation + Dashboard modules
- Performance & Scalability — recent improvements mostram 3x speed increases
- Enterprise Features — SSO, advanced permissions, audit logging
Scoring methodology para priorização: 6 drivers (Adoption, Revenue, Strategy, Development Effort, Operational Impact, Risk) cada um scored 1-6, com adoption e dev effort weighted higher. Scripts sincronizam GitLab issues com internal Baserow database para gestão flexível. Ciclos de release de 4 semanas com extensive testing.
Crescimento 2024: 300% YoY ARR growth, ~100k total users, 20 dedicated Ambassadors, 600+ open issues sendo gerenciados, 180+ features shipped em 2024.
Baserow incorpora uma filosofia "unapologetically pro-open source" construída sobre transparência, trust e colaboração comunitária.
Três pilares culturais:
Openness: "Our code, product, and community are all in the open for everyone to join and contribute to". Transparência está "at the core of everything we do". Deliberadamente escolheram "the path that includes high loads of feedback, issues pin-pointing, and suggestions".
Trust: "We trust each other and our community". "We trust each other to be autonomous and build Baserow to the best of our abilities". Time fully remote com flat hierarchy e sem micromanagement.
Blameless Philosophy: "We understand that mistakes are caused by bad processes and not people". Foco em continuous process improvement em vez de culpar indivíduos.
Full-Stack Ownership Model: Contratam desenvolvedores full-stack experientes em backend e frontend. Desenvolvedores individuais podem construir features significantes do zero. "Developers should have ownership over their tasks and not constantly rely on others". Essa abordagem permite "ship features quickly without sacrificing code quality".
Small, Focused Teams: Time de desenvolvimento dividido em teams menores responsáveis por partes específicas do codebase. Cada team: alguns full-stack developers + tech lead.
Workflow: Assigned issue → functional description + UI/UX design → optional technical plan → code review → merge.
4-Week Cycle Discipline: Trabalham em ciclos rígidos de 4 semanas com planning meetings após cada release. "Regardless of progress, we prepare for a release" após 4 semanas. Deploy para Baserow.io hosted primeiro, depois official release para self-hosters uma semana depois. Garante "release content is well-prepared, runs stably, and makes it easier to fix bugs".
Data-Driven Scoring System: Baserow usa metodologia sofisticada de 6 drivers:
- Adoption (higher weight)
- Revenue
- Strategy
- Development Effort (higher weight, inverted — less effort = higher score)
- Operational Impact
- Risk
Cada scored 1-6, com adoption e dev effort recebendo extra weight "porque estamos em early stage e temos recursos limitados de desenvolvimento".
Technical implementation: Script sincroniza GitLab issues com tabela Baserow, permite mixing feature requests, adicionar non-issue tasks, armazenar customer request data. Scores synced de volta para GitLab weight column para visibilidade pública. Resulta em lista de features priorizada publicamente visível.
Strategic Alignment Filter: "If a feature request does not align with that goal, then it will not make it on the roadmap". "We have a good idea of what the product should look like in a couple of years, and we try to stick with that, instead of becoming a jack of all trades". Dispostos a dizer "não" para great ideas que não se encaixam na direção estratégica.
Community-Driven Input: Weekly review de community feedback e feature requests. Decisão baseada em "value of the feature to a lot of other users". Features muito específicas para small user base não são priorizadas (usuários podem desenvolver eles mesmos).
Open-Core Business Model com 5 promessas explícitas:
- "Any feature present in the free open-source Baserow project will always remain free and fully open source"
- "The main Baserow codebase will always remain free and open source"
- "The majority of new features made by Baserow will be open source"
- "You will always be able to self-host Baserow for free with no restrictions on storage, data, or usage"
- "We will always offer the self-hosted option under the OSL definition"
MIT License Choice: Core product sob MIT License (mais permissiva disponível). Premium features em source-available (not open-source) add-on com proprietary license. Premium code ainda publicamente viewable para vetting/security review.
Evidence of Commitment: Blog post inclui gráfico mostrando code volume — massive foco no free open-source codebase vs premium add-on. "We are focused massively on the core open-source version of Baserow and are releasing features for it at a much higher rate".
Co-Creation Model: "We invite you to co-create with us by sharing your thoughts around Baserow". "Every member of our community deserves to be heard".
Community Forum: Dedicated Discourse forum em community.baserow.io. "2,000+ conversations and answered 500+ questions" em recent year. Direct engagement entre usuários e founders. "Founder Chat" initiative onde founders respondem perguntas da comunidade em dedicated blog posts.
Real Transparency Examples:
Reddit AMA (August 2022): Founders gastaram 3 horas respondendo todas questões openly. Discutiram funding pressures, business model decisions, shared technical regrets e future plans, explicaram feature prioritization em detalhe.
Public Roadmap Discussions: Feature scoring methodology published, prioritized issue list publicly visible, community pode votar em features.
"How We Build Baserow" Blog Series: Detailed explanations de internal processes, tech stack decisions com founder responses, development team structure shared openly.
Originalmente no GitLab (alinhado com filosofia open-source: "open source projects should be hosted on an open source platform"). Community member levantou concerns sobre GitLab limitar discoverability. Após "careful consideration", moveram para GitHub para greater reach. "This is not a decision we made lightly".
GitLab repo permanece como read-only mirror. Full explanation published: "We are not turning our back on GitLab". Thanked GitLab team publicamente while explaining rationale. Mostra willingness de fazer pragmatic choices para project growth enquanto acknowledging philosophical trade-offs.
Spreadsheet-Like Experience: "Unique way of offering a spreadsheet-like experience, while still being performant with lots of rows". Founder mais proud de grid view design. Target: "database as easy to use as a spreadsheet".
Performance como Non-Negotiable: "We think performance is very important in a tool like Baserow". "We have many ideas on how to make it even faster and are constantly implementing improvements".
Controlled Expansion: Started como database-only tool. Planned evolution: database → application builder → workflow automation. "We want to become an open source no-code toolchain". Cada módulo builds em previous: maintain simplicity dentro de cada enquanto expanding overall capability.
Saying No to Feature Creep: Recusaram MySQL/MariaDB support apesar de requests. Sem mobile app no roadmap (improving web mobile compatibility instead). Focus em becoming "open platform" não "jack of all trades".
Filosofia: "A fair and sustainable way of running an open-source project giving free access to most of our smaller users (solopreneurs, consumers, students, etc.) whilst providing value-added paid features for businesses".
Current status: €5M seed round (July 2022), team grew de 3 para 18 members (agora 17 humans + 6 cats + 3 dogs + 1 Tesla!), 7+ full-time developers, ~100k users, hundreds de paid customers, ~1000 signups por mês.
Pricing tiers: Free (unlimited self-hosted), Premium ($10/user/month), Advanced ($20/user/month), Enterprise (custom $15-35/user/month).
What's free vs paid:
Free: Core database functionality, unlimited rows/storage/users self-hosted, API access, basic collaboration, most new features, basic user management.
Paid: Advanced RBAC, SSO, priority support, audit logs, specific premium views, enterprise user management.
Community Insurance: "Having the code out in the open means we can never just disappear from the market". "The code is in the hands of the users, forever". No vendor lock-in by design.
Baserow representa uma masterclass em como construir um produto open-source sustentável que compete diretamente com incumbents proprietários. A sofisticação técnica está na geração dinâmica de modelos Django que permite que usuários não-técnicos criem schemas de banco de dados arbitrários enquanto mantém toda a robustez e segurança de PostgreSQL + Django ORM. O sistema de plugins baseado em registries e o padrão handler demonstram arquitetura pensada para extensibilidade e manutenibilidade a longo prazo.
As decisões técnicas — Django pela popularidade e batteries-included, PostgreSQL exclusivamente pelo poder e dynamic schema support, Nuxt.js pela simplicidade e SSR, REST puro pela clareza e Handler pattern — são pragmáticas e bem justificadas. O sistema de permissões plugável, multi-layer caching (Redis para models e SQL queries), field indexes opcionais, e arquitetura stateless horizontalmente escalável mostram maturidade enterprise-grade.
Mas o verdadeiro diferencial está na filosofia e execução. A equipe demonstra:
Transparência radical: Scoring methodology published, feature prioritization visible, founders answering Reddit AMAs por 3 horas, "How We Build Baserow" blog series revelando internal processes
Promises escritos e cumpridos: 5 explicit commitments sobre o que permanecerá free forever, MIT license para core (não apenas "source available"), gráficos mostrando código volume confirmando foco no free version
Pragmatismo com princípios: GitLab→GitHub migration para discoverability apesar de preferência filosófica, open-core model mas maioria das features no free version, taking VC funding mas maintaining MIT license
Disciplina de produto: Saying "no" a MySQL/MariaDB support, refusing feature creep, 4-week release cycles regardless of progress, strategic alignment filter para features
Full-stack ownership e blameless culture: Desenvolvedores owning features end-to-end, mistakes atribuídos a bad processes não people, flat hierarchy, remote-first com annual meetups
Performance 2024: 300% YoY ARR growth, ~100k users, 180+ features shipped, continuous improvements (600% faster formulas, 10x filtering com indexes), active development com releases a cada 4 semanas.
O resultado é um produto que entrega poder enterprise-grade (unlimited rows, RBAC, SSO, audit logs, horizontal scaling) com UX simples (spreadsheet interface, drag-and-drop, real-time collaboration) e freedom completa (MIT license, auto-hospedagem ilimitada, source code viewable, plugin system). Não é surpresa que organizações em banking, insurance, pharma, research, healthcare e government estejam usando Baserow em produção.
Para desenvolvedores e organizações priorizando data sovereignty, evitando vendor lock-in, e precisando de capacidades de banco de dados production-grade com interface no-code, Baserow representa não apenas uma alternativa viável ao Airtable, mas frequentemente uma escolha superior. A combinação de technical excellence, genuine open-source commitment e transparent community engagement posiciona Baserow para continuar crescendo como líder no espaço de no-code databases.
Quote final que resume tudo: "Our goal is not only to create an awesome project that will help people and businesses alike; we want to help others develop their skills and creativity for the collective good."