La causa número uno son los índices. Con doscientas filas de prueba, buscar un dato es instantáneo aunque haya que recorrer la tabla entera. Con doscientas mil, esa misma consulta recorre doscientas mil filas cada vez que alguien abre la pantalla. Un índice le da a la base de datos un atajo, y sin él el crecimiento se paga entero en cada consulta.
La segunda es pedir muchas veces en vez de pedir bien. Es un patrón muy típico del código generado: se pide la lista de elementos, y luego, por cada elemento, se hace otra consulta para traer su autor o su categoría. Con diez elementos son once consultas y no se nota; con cien son ciento una y la pantalla se arrastra. Se arregla pidiendo los datos relacionados de una vez.
La tercera no es un problema de rendimiento sino de plan: los proyectos gratuitos de Supabase se pausan tras un tiempo sin actividad y tienen menos recursos. Ahí el primer acceso tras la pausa tarda muchísimo y luego va bien, que es un patrón muy reconocible.
Y un caso menos evidente: traer más datos de los que enseñas. Si la pantalla muestra veinte elementos pero la consulta trae los cinco mil que hay, el tiempo se va en transportar datos que nadie va a ver.