K6 + Firestore: a good match?

Hey all,

This is a question about firestore, and loading lots of javascript into my k6 tests.
Want to ask before investing a lot of time into dig into this help article.

My app is using the Firestore front-end web sdk. There is no “back end” that handles api requests, as the front-end uses built-in methods to create/fetch data.

So I cant test Firebase using k6 http requests. I’d need to import firestore js packages and use those to make the requests.

Something like this:

// firestore_helper.js
import { doc, getDoc, getDocs, collection, setDoc } from 'firebase/firestore';

// api call to firestore
export const get = () => {
  const ref = doc(db, collectionName, uid);
  return getDoc(ref).then(resp => resp)

// k6-test.js
import { get } from './firestore_helper'

export function foo() {
  // send request to firestore
  const request = get()
  // use k6 to test request here

So does this seem feasible in k6?
I don’t know all what web apis firestore relies on, but it’s certainly designed to run in the browser…


Hi @vaporwave, welcome to the community forum!

So I cant test Firebase using k6 http requests. I’d need to import firestore js packages and use those to make the requests.

Obviously those js packages do something to get the data, and it seems like they just do HTTP requests.

There seems to be a REST API docs, but I am not familiar with firestore.

A quick google search found this blog on how to use it with axios (which is mostly irrelevant).

Depending on your use case just writing some helpers using the k6/http calling the REST API will likely be enough.

But you will have a lot more problems if you just want to use the firestore js SDK. Again they will need to somehow do the requests and this likely will mean using the Fetch API, which is not supported by k6.

I would expect you will be able to polyfill it somewhat, but I am not certain how much work that will be beyond the smallest of examples and likely it will not be easy ;). Also I can’t find the firestore js SDK (easily) so can’t tell you if modifying that will not be easier.

On the other hand - what exactly do you expect to load test? Firestore itself? Google likely has clauses against load testing it’s infrastructure and this likely will cost you a pretty penny even if they do not (or don’t flag you :wink: ).

So I am not particularly certain if you even should be doing this .Maybe a bit more info on what you want to achieve will help us.

I just wanted to raise your awareness @vaporware that Firebase bills by the request volume, if I’m not mistaken, and that load testing your Firebase-backed systems might incur potentially much higher costs.

You’re probably already aware of it and got this plan, but I just wanted to make sure it’s said to avoid potential assumptions and mistakes leading to the kind of horror stories I heard of during my years using it.


Thanks for all the feedback @mstoykov

Not sure if Firestore uses the fetch api but it’s a good bet.
Which means writing a bunch of code to polyfill or use the REST api like you mentioned.

Our app is used at an event, and I want to simulate running the entire event. When we had a Ruby backend K6 was great for running scenarios against the api.

The Firebase docs say something like 10,000 requests/second so really I shouldn’t be concerned with scaling overall. There are idiosyncrasies though. E.g. Firebase can’t update the same doc more than once per second.
I just don’t want to miss anything. We’ve crashed our server in the past and it’s such a pain during the event. I want to be prepared.

But to your last point, yeah I’m basically asking about stress testing the firebase server. I didn’t realize they don’t like that, so thanks for the heads up.

I did run a quick test using our app. Created 5k docs in about 1 minute, which def is enough for our use-case.

Thanks for the headsup @oleiade.
Yeah I did read that part. The costs seem so low like 0.06 per 50K reads, but I should keep an eye on it.

Unexpected bills - yikes :grimacing:

Out of curiosity, did you stop using it for any particular reason? (If I’m reading your last sentence correctly)

@vaporwave In my experience, the firebase stack is excellent.

But I find it shines in certain kinds of scopes: rather small web or mobile applications with a limited supply of development time that can be easily traded for money. It’s, however, quite costly, and its APIs and SDK are quite opaque, huge, and sometimes a bit too opinionated for my taste. I used it in the past for a personal project, and would do it again though: it’s great when you want to actually focus on getting your project out the door, rather than have to build a whole infrastructure. There are good alternatives for the mobile use case now, though: apple, mongo atlas, AWS (I think it does that too now), etc…

Hope that’s helpful :bowing_man: