Supabase vs Airtable: qué usar de backend de tu app

Airtable es cómodo hasta las 50.000 filas. Supabase es incómodo hasta que lo necesitas.

Ese es el resumen entero, y si te vale con eso ya puedes cerrar la pestaña. Pero la parte interesante es dónde cambia exactamente la cosa, porque casi todo el mundo se cambia tarde y unos cuantos se cambian demasiado pronto.

Yo he montado apps con las dos. Y las dos veces el problema no fue la herramienta, fue haber elegido sin saber qué iba a pesar más dentro de seis meses.

¿Qué significa "backend" cuando no eres programador?

El backend es donde vive tu información. Los clientes, los pedidos, los usuarios, las notas. La parte de la aplicación que nadie ve pero que aguanta todo lo demás.

Cuando montas una app con IA, la parte visual la resuelve la IA en un rato. Lo que decide si tu app sobrevive es dónde guardas los datos, porque eso no se cambia fácil después. Cambiar el color de un botón es un minuto. Cambiar de base de datos con seiscientos registros dentro es un fin de semana.

Por eso esta decisión merece diez minutos de pensar y no tres segundos de "pues Airtable, que lo conozco".

Airtable: la comodidad tiene un techo, y el techo se ve venir

Airtable

Eso último importa más de lo que parece. Cuando algo va mal en tu app, poder abrir la tabla y mirar los datos con los ojos te ahorra horas. En Airtable eso es un clic. En una base de datos de verdad hay que preguntar con lenguaje de consultas o montar una pantalla para verlo.

El techo de Airtable no es la comodidad, es el volumen y la velocidad de la API. Cuando tu app empieza a leer y escribir muchas veces por minuto, notas la latencia. Y cuando las tablas engordan, los planes que te permiten seguir creciendo dejan de ser baratos.

Hay otro techo menos comentado: los permisos. Airtable controla quién ve qué a nivel de base y de vista, no a nivel de fila con la finura que necesita una app con usuarios de verdad. Si tu aplicación tiene clientes que solo pueden ver sus propios datos, eso se acaba resolviendo con parches.

Supabase: incómodo tres días, tranquilo tres años

Supabase es una base de datos PostgreSQL de las serias, con autenticación de usuarios, almacenamiento de archivos y una API que se genera sola encima de tus tablas.

La primera vez que lo abres te vas a sentir fuera de sitio. Hay tablas, hay tipos de datos, hay relaciones y hay una cosa que se llama Row Level Security que decide qué fila puede ver cada usuario. Nadie que venga de hojas de cálculo entiende eso de primeras.

Aquí es donde ha cambiado el panorama de verdad. Con una IA delante, ese muro se cruza hablando. Le describes qué tienes que guardar y qué usuarios hay, y te propone la estructura, te escribe las reglas de permisos y te explica qué está haciendo en cada paso. La parte que antes exigía saber, ahora exige preguntar bien. Es justo el salto que conté en el tutorial de Supabase como base de datos de tu app con IA.

Lo que sigue costando es la ausencia de una hoja bonita donde mirar tus datos. Existe el editor de tablas y funciona, pero no invita a trastear como Airtable.

¿Airtable o Supabase para guardar los datos de mi app?

Vamos a lo concreto, que es lo que has venido a buscar.

Elige Airtable si tu app la vais a usar tú y tu equipo, si el número de registros no va a pasar de unos pocos miles, si necesitas ver y editar los datos a mano cada semana, y si prefieres tener algo funcionando el viernes antes que algo perfecto el mes que viene.

Elige Supabase si tu app va a tener usuarios de fuera que se registran, si cada usuario solo puede ver lo suyo, si prevés decenas de miles de registros, o si esto es un producto del que quieres cobrar. También si te da urticaria depender del precio que otro decida subirte el año que viene.

Y hay un caso mixto que uso más de lo que confesaría: Airtable para el prototipo de las dos primeras semanas y Supabase en cuanto la idea demuestra que aguanta. Migrar 300 filas es una tarde. Migrar 30.000 es otra cosa.

Tabla comparativa

| Herramienta | Para quién | Precio real | Límite | Veredicto | |---|---|---|---|---| | Airtable | Equipos pequeños, herramientas internas, prototipos | Plan gratuito muy limitado y planes de pago por usuario y mes que suben rápido con el equipo. Confirma en la web oficial | Registros por base y velocidad de la API; permisos por fila pobres | Gánate las dos primeras semanas con esto | | Supabase | Apps con usuarios reales, productos que se cobran | Nivel gratuito generoso y planes de pago por proyecto al mes. Confirma en la web oficial | Curva de entrada; sin vista tipo hoja de cálculo cómoda | La opción que aguanta cuando la cosa va en serio | | Airtable primero y Supabase después | Quien no sabe todavía si la idea vale | Suma de los dos durante un mes | Hay que migrar, y migrar cuesta | Lo que hago yo casi siempre | | Google Sheets | Pruebas de un fin de semana | Gratis | Se rompe con concurrencia y con volumen | Vale para validar, no para vivir |

Si no quieres pensar: empieza en Airtable, ponle una fecha de revisión a un mes vista y si sigue vivo lo mueves a Supabase. Es la ruta que menos veces me ha salido mal.

El error que más caro me ha salido

Montar la app primero y decidir la base de datos después.

Suena obvio dicho así, pero cuando trabajas con IA la tentación es enorme: le pides una app, te la construye entera con los datos guardados donde a ella le ha parecido, y tú lo descubres cuando ya hay información dentro que te importa.

Ahora hago lo contrario. Primero decido dónde viven los datos y con qué estructura, se lo digo explícito, y luego construimos encima. Añade quince minutos al principio y quita días después.

Si estás empezando y todo esto te suena a idioma extranjero, tengo el recorrido ordenado desde cero en la guía para crear apps sin programar, y la comparación de las opciones sin código para llevar datos y clientes está en bases de datos y CRM sin código.

Y ahora qué

Coge tu idea y contesta tres preguntas por escrito.

¿Quién va a meter datos aquí, solo tú o desconocidos? ¿Cuántos registros habrá dentro de un año, cientos o cientos de miles? ¿Necesitas mirar y tocar los datos a mano cada semana?

Con esas tres respuestas la decisión se toma sola. Y si dudas, empieza por lo cómodo con fecha de caducidad puesta en el calendario. Lo peor no es elegir mal, es no haber decidido nunca y descubrirlo con la app llena.

Si no sabes por dónde entrar a todo esto, hice un test corto que te dice qué tipo de constructor eres y con qué herramientas empezar.

Hacer el test de IA