Graphik is a Backend as a Service implemented as an identity-aware document & graph database with support for gRPC and graphQL

Problem Statement

Traditional relational databases are powerful but come with a number of issues that interfere with agile development methodologies:

  • database schema setup requires application context & configuration overhead
  • database schema changes are often dangerous and require skilled administration to pull off without downtime
  • password rotation is burdensome and leads to password sharing/leaks
  • user/application passwords are generally stored in an external store(identity provider) causing duplication of passwords(password-sprawl)
  • traditional database indexing requires application context in addition to database administration

Because of these reasons, proper database adminstration requires a skilled database adminstration team(DBA).

This is bad for the following reasons:

  • hiring dba's is costly
  • dba's generally have little context of the API accessing the database(only the intricacies of the database itself)
  • communication between developers & dba's is slow (meetings & JIRA tickets)


Traditional non-relational databases are non-relational

  • many times developers will utilize a NOSQL database in order to avoid the downsides of traditional relational databases
  • this leads to relational APIs being built on non-relational databases

Because of these reasons, APIs often end up developing anti-patterns

  • references to related objects/records are embedded within the record itself instead of joined via foreign key
    • as an API scales, the number of relationships will often grow, causing embedded relationships and/or multi-request queries to grow
  • references to related objects/records are stored as foreign keys & joined client-side via multiple requests(slow)

Traditional non-relational databases often don't have a declarative query language

  • declarative query languages are much easier to build via graphical tooling for since a single query "console" is generally the only requirement.
  • without a declarative query language, interaction with the database often involves complicated forms on a user-interface to gather user input.
  • declarative query languages open up database querying to analysts, operators, managers and others with core competencies outside of software programming.

Traditional non-relational databases often don't support custom constraints

  • constraints are important for ensuring data integrity
  • for instance, you may want to apply a constraint to the "age" field of a user to ensure it's greater than 0 and less than 150
  • this leads to developers enforcing constraints within the applications themselves, which leads to bugs


No awareness of origin/end user accessing the records(only the API/dba making the request)

  • database "users" are generally expected to be database administrators and/or another API.
  • 3rd party SSO integrations are generally non-native
  • databases may be secured properly by the dba team while the APIs connecting to them can be insecure depending on the "origin" user

This is bad for the following reasons:

  • dba teams falsely assuming their database resources are secured due to insecure APIs
  • api teams falsely assuming their api resources are secured due to insecure database administration


  • a loosely typed Graph database with built in identity awareness via a configured identity provider(Google, Microsoft, Okta, Auth0, etc)
    • relational-oriented benefits of a SQL database
    • non-relational-oriented productivity benefits of a NOSQL database
  • zero password management- this is delegated to the configured identity provider
  • schema-optional for productivity gains - constraints enforce custom constraints when necessary
  • "identity graph" which creates automatically creates connections between users & the database objects the create/modify
    • index-free-adjacency allows insanely fast relational lookups from the POV of the origin user
  • fine-grained authorization model to support requests directly from the origin user/public client(user on browser, ios app, android app, etc)
    • enforce role-based-access-control based on attributes found on the profile of the user manged by the identity provider
  • graphQL API to support a declarative query language for public clients(user on browser, ios app, android app, etc), data analysts, and database administrators
  • gRPC API for api -> database requests - gRPC tooling server side is more performant & has better tooling
    • auto-generate client SDK's in most languages (python, javascript, csharp, java, go, etc)
  • database schema operations managed via integration with state of the art change management/automation tooling - terraform