"Flutter Gemini Chatbot with Supabase Chat History"
"Most Flutter chatbot tutorials lose everything on restart. This one builds a Gemini chatbot whose memory lives in Supabase — per-user threads, RLS-scoped, reloaded into startChat, and synced live across devices."
Picture this: a user opens your app on Tuesday and your chatbot says, "Welcome back — want to continue where we left off yesterday?" That single moment is the difference between a demo and a product people keep. Search "flutter gemini chatbot supabase chat history" and you'll mostly find repos that store messages but never reload them — memory that only goes one way. This guide builds the real thing: every conversation persisted per user in Supabase, reloaded into Gemini's memory on every launch, and synced live across the user's devices. Most tutorials stop at an in-memory message list that evaporates on restart. We won't. What you'll build and learn An ai_conversations + ai_messages schema in Supabase with per-user RLS Saving both sides of every Gemini turn to the database Loading history back and mapping rows into startChat(history:) — the keystone step Streaming replies with generateContentStream for a live feel Supabase Realtime so chat syncs across the user's phone and tablet A token-budget rule that keeps long histories from exploding your costs Which memory strategy fits your app (decision table included) The architecture The flow is a loop: the Flutter UI sends the user's message to Gemini through firebase_ai ; after the reply arrives, both messages are written to Supabase; on the next app launch, the recent thread is read back and injected into the chat session as history. Supabase Realtime watches the messages table so a second device sees new messages instantly. Think of memory in three tiers. Session context is what Gemini sees right now — the injected history. Persistent threads are the Supabase tables — the durable record. Semantic recall (embeddings + pgvector) is the optional third tier for "what did I tell you last…