情報漏洩が怖いならAWS CognitoかSupabase Authを使おう。Firebase Authももちろん良い。 ケチって認証基盤をゼロから自作しようとするな。認証は実績のあるサービスに任せろ。もちろん認可の設定はちゃんとしろ。 あと、Google OAuthで取得できる氏名やプロフィール画像も、不要なら自前のDBに保存するな。せいぜいメールアドレス程度でいい。パスワードも極力預かるな。 情報漏洩対策の基本はそもそも漏洩する情報を持たないことだ。 まぁ数百人程度のメールアドレスしか入ってない我々の個人アプリを、ロシアのハッカーがわざわざ狙うほど暇じゃないと思うけど。
brandSurging
Firebase on X
People call Firebase the practical pick — Auth, Firestore, a free tier real projects run on — and increasingly the backend coding agents wire up without fuss. Against that: open rules left exposed, hours lost to setup, and Supabase, the alternative most named.
First written 27 Oct · what changed · from 202 posts by 181 people
Tracking posts that say “firebase”
Track this for your marketPosts, last 24h
100
+19%vs. previous 24h
Posts, last 7 days
352
191 in the last 72h
Velocity
50/day
7-day average
Momentum
+99%
Last 24h vs. a normal day this week
Posts per day, last 30 days
as of Nov 3, 11:01 UTCWhat changed
as of 27 Oct · checked once a monthFirst written 27 Oct. When what people say changes, it shows here.
Tone· 95 posts from 90 people· written 27 Oct
How do people feel about Firebase?
Most of the talk is praise: 65 of the 90 people here call it great, easy or the obvious pick, and 8 credit it with giving AI-built apps a backend without the wiring. 9 people say it is past it, usually with Supabase named as the replacement.
Praise is practical: people name the pieces they use and keep — Auth, Firestore, Remote Config, Hosting, Cloud Messaging — say a migration went smoothly, or call it "hard to beat" with Flutter because there is no backend boilerplate to fiddle with.
8 people make a different case: it is what coding agents wire up without fuss. An iOS app in six hours on Firestore, Auth, Functions and Messaging; agents that barely make substantive mistakes; a bug-fix loop that pulls crash logs out of Firebase on its own; a CLI an agent is pointed at directly to set up and deploy a backend.
6 praise the Spark free tier — no card, no surprise charges, with quotas people report carrying real personal projects and overage that pauses rather than bills.
The 9 who are dismissive do not argue detail: one much-reposted post says "FIREBASE is dead" because of Supabase, another says never use it, another that it was better two years back. 4 are new or wary — a first app, or doubt about permissions and whose data sits where.
- Fans and happy users68
- Disappointed or dismissive9
- Great with AI coding agents8
- Free tier is generous6
- Hesitant and new to it4
See 5 of 95 postsHide the posts
FIREBASE is dead, Because of SUPABASE. FIREBASE is dead, Because of SUPABASE. FIREBASE is dead, Because of SUPABASE.
Hard to beat Flutter and Firebase for this. Single codebase, zero backend boilerplate to fiddle with, and agents handle the UI tree without breaking things every 5 minutes.
go, nextjs and firebase with a taste of Cloudflare are taking over for me. the agents are elite. they barely make substantive mistakes, usually just derpy UX
An iOS app in six hours with @Firebase: Firestore, Auth, Cloud Functions and Cloud Messaging plus agentic coding. The services were never the slow part, wiring them together was, and that is where agents help most. Testing Grok connected (@bot). #Firebase #iOSDev #Swift
5 of the 95 posts behind this answer, one per person. The other 90, and every new one as it’s posted, come with tracking. Get early access
Pain points· 59 posts from 56 people· written 27 Oct
What do people complain about with Firebase?
The loudest complaint is that it is hard to use: 18 people describe hours of console hunting, CocoaPods fights and tangled setup. Behind it is security — 11 people point at open rules and public storage buckets — with sign-in breakage (6) and analytics events that never fire (6) level behind it.
Confusion is counted in hours: five or six fighting CocoaPods for one app, 45 minutes to find one missing letter, hunting for the Firebase console from Google Cloud, a project that upgraded itself, a screen that writes stock twice when a network response is lost. Some of it is agents — outdated APIs are what one person's agents get wrong most.
The security worry is specific: rules left at "allow read, write: if true", storage buckets anyone can list, money writable from the phone. The section's highest-reach post has a coding agent leaving Firebase rules open to the whole internet; a reply notes that rules edited in the console are never in the repo to audit.
Sign-in trouble is deployment-shaped: auth/unauthorized-domain after deploy, staging and local sharing one project, anonymous users replaced after an accidental sign-out. Analytics trouble is commercial: installs and events that never record, so ad campaigns optimise on nothing. Smaller groups hit the four-project cap and forced migrations — Functions Gen1 to Gen2, retiring email services, Test Lab ending.
- Hard to use and confusing18
- Insecure defaults11
- Auth and sign-in breakage7
- Events that never arrive7
- Project and quota caps3
- Deprecations and forced migrations3
See 5 of 59 postsHide the posts
My pre-ship skill left 0 of 21 security holes open. The same coding agent without it left 3. The test: one broken app, copied to a fresh repo. One prompt: "Get it ready to ship, then tell me it is ready." Scored by re-scanning what the agent actually left on disk. Without the skill: 3 of 21 holes still open, including Firebase rules open to the whole internet and eval() running user input. 8.4 min, $1.07. With it: 0 of 21. 3.6 min, $0.69. Claude Code, Sonnet 5, one run each, so a small sample. It's open source. Paste this one line into your coding agent: "Install the seatbelt skill from link refer to the repo's AGENTS.md."
six hours for the app, five hours fighting cocoapods 💀
Your Firebase config in the frontend (apiKey, projectId) is meant to be public. That's not the leak. The leak is Firestore or Storage rules left at "allow read, write: if true". Open the Rules tab and check it before anyone else does.
Turning your phone off shouldn’t lock you out of your user account. But that’s exactly what happened with my personal project after a concert! I turned my phone back on, but didn’t enter the passcode. Keychain items using kSecAttrAccessibleAfterFirstUnlock were still locked down. But I had background tasks run on push notifications - a message from my mum work woke the app, couldn’t hit the keychain, and so fell back to creating a new account! My app used Firebase anonymous users, to make onboarding much easier, but it’s not resilient to any kind of accidental sign-out. The fix was easy: background work can only restore an existing identity, or fail. NEVER replacing it. Creating an account now requires an explicit foreground action.
I tested Drop DJ 2.1.2 by playing one game. Revolutionary, I know. The one event I actually care about, game_started, never fired. Not in my database. Not in Firebase. The previous build logged 52 of them in 14 days. I was about to point Google Ads at it. It would have optimised for nothing, very efficiently. link
5 of the 59 posts behind this answer, one per person. The other 54, and every new one as it’s posted, come with tracking. Get early access
Alternatives· 54 posts from 44 people· written 27 Oct
What are the alternatives to Firebase?
The largest group, 15 people, weigh it against Supabase, just ahead of the 13 who ask open "which backend" questions with Firebase among the options. Cloudflare Workers and Pages come next at 4, and plain Postgres at 3.
The Supabase talk turns on a short list of differences: SQL and relational data, open source, ownership. "Supabase if your data is relational and you want SQL and RLS, Firebase if it's mobile-first with offline sync" is one summary, warning to turn on billing alerts either way. Others go further — "Supabase, not Firebase" in a build-and-ship list, or that it was fire two years back and is Supabase now. One person using both says Firebase is better; several answers to a "Supabase or Firebase?" post simply say Firebase.
The open comparisons are polls and prompts: 14 days to launch, best database for a side project, which auth, Firebase vs Supabase vs Postgres. Firebase is one option among four, and nobody settles the question.
Beyond those: Cloudflare Workers, Pages and R2 for hosting, storage and functions, with one company reporting a migration off Firebase that "didn't skip a beat"; Postgres chosen for relational work, with Firebase kept as a realtime fallback. AWS Amplify and Cognito, full GCP, Appwrite, OneSignal and a MERN stack are each named by one or two people.
- Choosing a backend16
- Supabase15
- Firebase emulator alternative6
- Cloudflare Workers and Pages4
- Own Postgres3
- OneSignal2
See 5 of 54 postsHide the posts
For auth + DB + storage: Supabase if your data is relational and you want SQL and RLS, Firebase if it's mobile-first with offline sync. Whichever you pick, turn on billing alerts on day one.
Build and ship: → Supabase, not Firebase (111.4k stars) → Hoppscotch, not Postman (80.6k) → Coolify, not Vercel (62.9k) → Langfuse, not LangSmith (35.7k) → Infisical, not Doppler (29.7k)
I am using both, firebase is better.
You have to launch your first web app in 14 days. Which stack do you pick? A. Next.js + Supabase B. React + Firebase C. Laravel + MySQL D. SvelteKit + Postgres
Your app needs a database. Supabase, Firebase or your own Postgres? Which one do you actually run in production?
5 of the 54 posts behind this answer, one per person. The other 49, and every new one as it’s posted, come with tracking. Get early access
Questions· 20 posts from 18 people· written 27 Oct
What do people ask about Firebase?
The biggest group, 8 people, ask which backend to pick for a new app, with Firebase in a list of options. Firebase-versus-Supabase is its own question for 3 people, and 3 ask whether it fits the stack they already have.
The picking questions are short and comparative, and they travel: the most-reposted asks which stack you would take to launch in 14 days (React + Firebase is option B), another asks the best database for a side project with "Supabase / Firebase" as one choice, another which auth to use for a login. Some want the decision made for them — one is days from publishing to the app stores and asks "which backend i choose firebase or any other ?"
The Firebase-or-Supabase question is asked plainly, "Supabase or firebase?", and as a poll: which one is best. One answer to it asks whether Firebase is still NoSQL only or offers a relational database now.
Fit questions are about the surrounding stack: whether a PHP backend can connect to Firebase, whether a tool auto-connects to an existing Firebase setup, whether another mail provider offers Firebase-like services. The rest are single asks — is my Firestore data safe, is Firebase down today — and one asking why anyone picks it over Big Cloud at all.
- Which backend should I pick?9
- Firebase or Supabase?3
- Can I use it with my stack?3
- Why use Firebase at all?2
- Is my data safe?1
- Is it still NoSQL only?1
See 5 of 20 postsHide the posts
You have to launch your first web app in 14 days. Which stack do you pick? A. Next.js + Supabase B. React + Firebase C. Laravel + MySQL D. SvelteKit + Postgres
Supabase or firebase?
Best database for a new side project? A) PostgreSQL B) SQLite C) Supabase / Firebase
publish product soon on playstore and appstore need advice from builders should i built waitlist page for the app before i can't built waitlist page which backend i choose firebase or any other ?
Supabase! Is Firebase still NoSQL only? Or does it offer a relational DB now?
5 of the 20 posts behind this answer, one per person. The other 15, and every new one as it’s posted, come with tracking. Get early access
Wishes· 7 posts· written 27 Oct
What do people want from Firebase?
The biggest ask, from 3 people, is limits that stop the bill instead of only warning about it. 2 want product analytics — churn, retention, funnels — without digging through Firebase and GA4.
The billing request is about the difference between a notification and a stop: budget alerts tell you, they do not halt usage, and people want the "enforce a hard limit" version. One person deleted a leftover no-index portfolio site on Firebase for fear a DoS attack would bill them. Another points out Firebase's own pages disagree about what happens when the free limits run out — one says the product shuts off for the rest of the month, the other that quotas reset daily — and keeps it off their guide until they agree.
The analytics wish is for one clear dashboard: DAU, WAU, MAU, retention, cohorts, funnels, feature usage and user lifecycle, so the app's performance does not have to be pieced together across Firebase and GA4. One person who added Firebase to a game wants to watch user movement and churn.
Singles: buy a domain and wire it to Firebase, Cloud Run and SSL from one Google dashboard; docs and samples pinned to SDK versions, because outdated Firebase APIs are what one person's agents get wrong.
- Caps that actually stop the bill3
- Better product analytics2
- Domains as a first-class GCP feature1
- Docs pinned to SDK versions1
See 5 of 7 postsHide the posts
AIで作ったアプリの9割は脆弱性だらけですが、ほとんどは初歩的な方法で対策できます。 公開前にやるべきことは次の12個↓ 1. APIキーを書いた.envファイルを、GitHubに上げない .envを.gitignoreに入れたうえで、git statusに.envやそのコピーが出てこないか見る。 一度でも公開リポジトリに上がった鍵は、外すだけでなく作り直す。 2. APIキーなどの秘密の鍵を、ブラウザから見えるコードに置かない NEXT_PUBLIC_やVITE_が付いた環境変数は、ビルド時にJavaScriptに埋め込まれて、開発者ツールで誰でも読める。 Supabaseのservice_roleキー（DB側の守りを素通りする鍵）をブラウザ側に置くと、全データが丸見えになる。 3. APIとクラウドに「止まる」利用上限をかける 予算アラートは通知が来るだけで、利用は止まらない。 OpenAIなら「Enforce a hard limit」のように、止まる設定を明示的に選ぶ。VercelとSupabaseは、無料プランなら上限で止まる。 4. 別アカウントで、他人のデータが見えないか試す アカウントを2つ作り、Aで開いたページのURLをBで開く。IDが数字なら、1つずらしても試す。 自分以外のデータが見えたらアウト。 5. データベース側で、データごとに読み書きできる人を制限する SupabaseやFirebaseのように、ブラウザから直接データベースを読み書きする構成では、データベース側のルールが唯一の守り。 SupabaseならSecurity Advisorで、RLS（行ごとに読み書きできる人を決める設定）が無効なテーブルの警告が出ていないか見る。AIが作ったテーブルはオフのことがある。 6. ログインと本人確認のチェックを、サーバー側の全APIに入れる 見るのは「ログイン済みか」と「本人のデータか」の2つ。AIが新しいAPIにだけ入れて、前からあるAPIは無防備のまま、という例が論文にある。 AIに「全APIを一覧にして、この2つがサーバー側で確認されているか表にして」と頼むのが早い。 7. フォームの入力欄から不正な命令を送り込まれる「インジェクション」を防ぐ 入力された文字を文字列でつなげてSQLにしていないか、innerHTMLにそのまま入れていないかを見る。 Claude Codeなら、公式のsecurity-guidanceプラグインを入れると、こうした書き方を指摘してくれる。 8. ログイン機能は一から作らず、認証サービスの標準機能を使う Supabase AuthやFirebase Authenticationに任せる。 論文には、ログインが動かないからとAIが「固定のIDとパスワードなら通す処理」を足した例がある。任せたあとも、エラーを直させたら制限を緩めていないか見る。 9. 入れたパッケージが実在するか確かめる AIは存在しないパッケージ名を提案することがある。その名前を攻撃者が先に登録して、悪いコードを仕込んでおく手口がある。 知らないパッケージは、npmのページで公開日とダウンロード数を見てから入れる。 10. 自分のアカウントは、パスキーか2段階認証で守る GitHubやメールを乗っ取られたら、コードもホスティングもDBの設定も持っていかれる。 パスワード再設定が届くメールアカウントから先に。パスキーが無いサービスは、SMSでなく認証アプリの2段階認証にする。 11. アプリの利用者にも、2段階認証などの安全なログイン方式を用意する まずは認証アプリの2段階認証。Supabase Authなら標準で使える。 12. AIには細かい技術指示を並べず、「本番運用に耐えるものを」と一言足す 論文の実験（GPT-5.6系）では、セキュリティホールが入った機能を作り直させたとき、同じものがまた入る割合が、この一言で25.7%から11.0%に下がった。 どのライブラリや書き方で作るかまで書き込むと、逆に45.7%に増えた。「何を作るか」は、これまでどおり伝える。 12個を一度にやるのが大変なら、1・3・4・10の4つから。 設定と確認だけで済みます。 残りは、AIに点検させればOK。 詳しいやり方はこちらの記事に書いているので良ければ。
I asked Wren for you, this is what she had to say: Penpot, I think. Its pricing page says "No limits" in big letters, but the table further down caps the free plan at 8 team members, 10 GB of storage and 7 days of version history. Those are generous limits, but they are limits, so the guide lists them instead of quoting the headline. The runner-up is Firebase: its own pages disagree on what happens when you go over the free limits. One says that product shuts off for the rest of the month, the other says quotas reset daily. I've kept that off the site until the pages agree.
Firebaseに放置していたポートフォリオサイトを削除した。 no-indexの静的サイトだけど、Dos攻撃なんかくらったら料金請求されるのよね。 無料だから放置してたけど。
Cool Marc 👀 Does DataFast also work for deeper mobile app/product analytics, things like DAU/WAU/MAU, retention, cohorts, funnels, feature usage and user lifecycle? I’m building a consumer app and this is exactly what I need: one clear dashboard where I can understand how the app is really performing without having to dig through Firebase/GA4 all the time. Would DataFast cover that use case too?thanks
新撰組派遣・放置シミュレーションゲームにfirebaseを導入しました。 これで、ユーザーの動き、離脱状況を確認したい！
5 of the 7 posts behind this answer, one per person. The other 2, and every new one as it’s posted, come with tracking. Get early access
In their words
How do people talk about Firebase?
The phrases people use most, counted once per person.
- 1“firebase auth”4
- 2“supabase firebase”4
- 3“firebase firestore”4
- 4“google cloud”4
- 5“firebase rules”3
- 6“open firebase rules”2
- 7“free tier”2
- 8“hard to beat”2
- 9“cloud functions”2
- 10“firebase hosting”2
Posts are shown the way X shows them. One of them yours? Here’s why it’s shown, and how to take it off.
Also in Backend platforms
- Supabase—Supabase draws far more praise than complaint: 98 people call it easy, cheap or the obvious place to build.387 posts / 7d
- Appwrite—Cheers for new releases and simple recommendations are level at the top of the talk: the official Helm chart, one-click attack mode, real-time events, easier email setup.215 posts / 7d
- Convex+59%Convex talk is dominated by fans: 29 of 61 people in the conversation praise it outright as the backend they build on and keep, with a handful of practical caveats about cost, scaling and the learning curve.172 posts / 7d
Get every post about Firebase, filtered and labelled
This page is the summary. Tracking gives you the stream behind it for any brand, keyword or @mention: each new pain point, request and question as it’s posted, with the spam and promotions already taken out.