↑ ↓ navigate↵ selectesc close

Data Connect: All About Schemas in Firebase: Web Architecture & Implementation Guide

CodingCat.dev tutorial cover image
Alex Patterson
Alex Patterson

For years, choosing Firebase meant trading away relational SQL joins, strict foreign keys, and pgvector similarity search in favor of NoSQL document denormalization. Following the announcement of Data Connect: All About Schemas by Andrea Wu on the Official Firebase Blog (2025-02-11), here is our hands-on CodingCat.dev breakdown of what actually shipped, how it works under the hood, and how we wire it into production TypeScript, Next.js, Astro, SvelteKit, React, and Angular applications. Note: Firebase Data Connect has been renamed to SQL Connect. Learn more in the SQL Connect announcement.

The Mental Model: Why Data Connect: All About Schemas Matters for Web Devs

As a Google Developer Expert (GDE) for Firebase and Senior Solutions Engineer at CodingCat.dev, I evaluate every Firebase update through one lens: does it reduce boilerplate while keeping our runtime security and cloud bills predictable? Firebase Data Connect bridges that gap by pairing a managed Google Cloud SQL for PostgreSQL instance with a declarative GraphQL schema compiler that automatically generates type-safe TypeScript, React, and Angular SDKs alongside server-enforced @auth directives.

AJ Pro-Tip from Alex: Keep your authorization logic inside your Data Connect GraphQL operations using @auth(level: USER) and server-evaluated expressions like auth.uid and request.time rather than trusting client-supplied user IDs in query variables.

How It Works: Technical Breakdown & Implementation

Many apps need to store persistent data, and most of the time, that data needs to be organized in a structured way. With Data Connect, you model your app data using schemas, and this blog post dives into what schemas are and how to use them.

We’ll use the movie review app example you might already know from the documentation and our previous deep-dive blog posts.

Declaring a Schema

Firebase Data Connect schemas are defined using GraphQL. The key components of GraphQL schema definitions are:

  • @table directive, which includes the optional arguments of naming convention and key(s)

Here is an example from the movie tracker app:

  • A type type definition, letting GraphQL know this is declaring a type (other examples of type definitions are query and mutation)
  • A directive @table which signifies creation of a schema

Within the @table directive, there are a few optional fields:

  • name: defines the table name; by default, the table name is the schema name
  • singular: for implicit queries and mutations, this defines the name that gets used in the query / mutation that requires this table
  • plural: for implicit mutations, this defines the name that gets used in the mutation that requires this table
  • key: an optional list for the name of the table’s key(s)

By default, the singular naming convention will be the name of the table with a lower case first letter, and the plural one will be the singular with a “s” at the end. You only need to use singular or plural to adjust the name if it is different than the default.

Similarly, the key by default will be named id, and you do not need to declare this when you declare a schema.

Removing all of the defaults, the above declaration can be simplified to:

Anatomy of a Schema

Now that you know how to declare a schema, how does a schema in its entirety look like? It is broken down into the following parts:

  • Declaration to create a schema, as described in the previous section

Here is an example schema for movies, written verbosely with all optional fields present except the schema declaration as covered above:

type
  id: UUID! @col(name: "movie_id") @default(expr: "uuidV4()")
  title: String! @col(name: "title")
  releaseYear: Int @col(name: "release_year") @index
  genre: String @col(name: "genre", dataType: "varchar(30)")
  rating: Int @col(name: "rating")
  description: String @col(name: "description")
}

Each line is the name of a column along with the data type of that column. Any data type followed by! means this attribute is required. Data Connect supports a wide range of data types, some of which are in this code snippet like UUID, String, and Int. UUID is a special data type that indicates that this is a unique ID, which is useful for keys.

You will also see @col, @default, and @index directives:

  • @col explicitly sets column information, including names and data type. The genre column is named “genre” with the String data type of at most 30 characters. By default, the first word of each line becomes the column name, so you only need @col(name: “...” if you want a different name.
  • @default lets you set default values. In the example above, an id defaults to a UUID generated by uuidV4().
  • @index defines a database index to optimize query performance. To create a single field SQL index, put @index on a @col field. You can specify order, but this doesn’t matter much for single field indexes as they can be scanned in both directions. To define a composite index, You can put @index(fields: [...]) on @table and define an order for each indexed column, defaulted to ASC. Above, releaseYear would be ordered in ascending order whereas rating would be ordered in descending order.

Removing all of the defaults, the above can be simplified to:

type
  id: UUID! @default(expr: "uuidV4()")
  title: String!
  releaseYear: Int @index
  genre: String @col(dataType: "varchar(30)")
  rating: Int
  description: String
}

Key Scalars

For databases optimized for speed, key scalars are an efficient way to identify objects. Data Connect automatically assembles these identifiers from key fields in your schemas, and the resulting scalars provide information about data identity and structure, accessible within a single cell. Key use cases include:

  • sequential operations: key scalars serve as unique identifiers for new records, simplifying subsequent operations
  • relational operations: key scalars provide access to relational keys, enabling more complex data manipulations

Server Values

Sometimes, your app might need server-computed values because the values need to be computed at the time of data creation. You can do this by using server values, where the server dynamically populates fields in your tables using stored or readily-computable values according to particular server-side expressions. For example, you can define a field with a timestamp applied when the field is accessed using the expression createdAt: Timestamp! @default(expr: "request.time"). This might be used when a user creates their account, so the schema could look like this:

type
  // other fields
  createdAt: Date! @default(expr: "request.time")
}

Relationships Between Tables

A big part of using relational databases is (surprise!): relationships between tables, and Data Connect lets you do that. Here is an in-depth blog post on how to define one-to-one, one-to-many, and many-to-many relationships in your schemas.

Production Web Architecture & Security Checklist

Whether we are deploying on Firebase App Hosting, Cloudflare Workers, or Vercel, shipping SQL features to production requires defense-in-depth across three layers:

  • Enforce Firebase App Check & Attestation: Protect your web endpoints, Cloud Functions, Data Connect GraphQL resolvers, and Firebase AI Logic calls against unauthorized replay or billing abuse using Firebase App Check with reCAPTCHA Enterprise.
  • Validate Locally with the Firebase Emulator Suite: Run deterministic integration tests against local Firestore, Auth, Functions, and Data Connect PostgreSQL emulators before promoting schema or rule changes to production.
  • Keep Server & Client Boundaries Type-Safe: Use the modular Firebase Web SDK and generated TypeScript bindings so SSR frameworks like Next.js, Astro, SvelteKit, and Angular serialize state cleanly without hydration flickers.

Conclusion

Accelerate your full-stack web and AI development by pairing Data Connect: All About Schemas with strict Security Rules, Firebase App Check, and local emulator testing. Come tell us on X (@CodingCatDev) and LinkedIn (CodingCat.dev) how you are using Firebase in your stack, and subscribe to the CodingCat.dev YouTube Channel so you don't miss what we build next!

Watch Our Related Firebase Video Tutorial on YouTube

Want to see how we architect and debug Firebase web applications live? Watch our related CodingCat.dev session Firebase SQL with Data Connect below, and make sure to Subscribe to CodingCat.dev on YouTube for weekly full-stack web and AI deep dives:

Resources, Official Docs & Related CodingCat.dev Guides

Frequently Asked Questions (FAQ)

What are the key capabilities introduced in Data Connect: All About Schemas?

Data Connect: All About Schemas (announced 2025-02-11 by the Firebase team) enhances the platform for Firebase, Google Cloud, Web Dev, SQL workloads. Note: Firebase Data Connect has been renamed to SQL Connect. Learn more in the SQL Connect announcement. Developers can review the primary announcement on the Firebase Blog alongside our implementation patterns and production checklist above.

How do web developers use Data Connect: All About Schemas with Next.js, SvelteKit, React, or Angular?

Web developers can integrate these features using the modular Firebase JavaScript/TypeScript SDK, Firebase Data Connect web bindings, and Firebase App Hosting. Always pair client-side SDK initialization with Firebase App Check and strict Security Rules, and test locally with the Firebase Local Emulator Suite before deploying.

Where can I watch video tutorials on Firebase Web and AI development?

You can watch our hands-on Firebase video walkthroughs on the CodingCat.dev YouTube Channel, including Firebase SQL with Data Connect, and follow us on X (@CodingCatDev) for weekly full-stack tutorials.