this one is a long-time coming and it's a continuation of our acquisition of Logflare[0]. Since the acquisition we've be open-source-ing the server, which you can find here: https://github.com/Logflare/logflare
Logflare handles about 1.5 billion log-events everyday on supabase. It's built with Elixir and has no problems with that workload.
This is really just the start of the Logflare updates. All logs are currently ingested into BigQuery, and we are adding support for Clickhouse and other backends (focusing primarily on open source backend). Over time Logflare will function very much like an open source Sentry alternative, where you can ingest data from various sources.
The team will be around if you have any questions about the technical implementation
Sorry for off topic question, but do you plan on doing anything about the egress prices?
I do understand that you are hosting your stuff on AWS, which is subject to AWS egress fees, but the egress fee is just way too much for any serious project (imho)
thank you thank you. the longer i spend as a dev the more i have infinite appreciation for better logging.
this is asking a lot but could we get a breakdown as to what you think are relevant decision factors for choice of logging server? (eg vs logstash/kibana, splunk and i guess people DIY with clickhouse but we can effectively ignore that)
> Logflare was available under a BSL license prior to joining Supabase. We’ve since changed the license to Apache 2.0, aligning it with our open source philosophy.
It would be awesome if this could use Quickwit as a backend which is a new promising alternative to Elasticsearch, I’ve been using it internally and it’s much more lightweight and easier to run.
> Simply provide your BigQuery credentials and we stream logs into your BigQuery table while automatically managing the schema
I didn't know BigQuery was capable of accepting streaming log data - in my mental model of the world it was the kind of database that you update using the occasional batch job, not from a streaming source of data.
It's pretty awesome & very cost effective! When I was at Twilio we streamed logstash/fluentd (forget which) -> kinesis -> BigQuery and it worked great - certainly better than the days we were trying to manage ES ourselves
I tried LogFlare (which is now Supabase Logs) in January, but it didn't work well for what I wanted.
Supabase Logs / Logflare seems primarily interested in creating graphs from logs rather than using logs for diagnostic purposes.
I've been looking for a log solution that's good for the use case of high retention but low volume.
I have a few small apps that generate a few MB of logs per month, so basically nothing. But I still want to have all my logs searchable in one place.
Most logging solutions set retention based on time rather than data size. So regardless of how much you're logging, they throw away your logs within somewhere between 7-30 days unless you're on an insane Enterprise plan.
I was excited about LogFlare because it supports unlimited retention, but I ran into too many issues and had to cancel my subscription:
* To search your logs, you need to write a SQL-like query in LogFlare's DSL. You can't just put in a route (e.g. /api/auth) like you can with other log analytics.
* Search only shows the matching lines. Usually, what I want to see is the log line in context. For example, if I search "catastrophic error" I want to see the log lines leading up to that, not just that specific line.
* Search is limited to a maximum of 100 results. If you want to see more results, you need to rewrite your query rather than just scroll up or hit a "load more" button.
* When you do adjust the query to a larger time window, the query will fail because it can't generate a graph unless you also adjust the group_by in your query to match the new time window's limits. This is an annoying obstacle if you don't care about graphing the results and are just trying to diagnose an issue in your logs.
I found support lacking as well. I emailed support to ask if I was misunderstanding how to use Logflare or if it was just designed for a different use case. I was on a paid plan, but I still had to wait 3 business days for a response. When the response came, they just said that it was designed for me but didn't address any of the issues I brought up.
I do like that Logflare/Supabase let you bring your own BigQuery. That's nice for customers like me who want low-volume, high retention. I hope they continue iterating because it has potential.
In the meantime, I've found LogTail to be a pretty good alternative, but they're limited to 30 days of retention even on the highest tier plan.
Firebase uses Google Cloud Logging. Taking a quick look at the blog post here, Google Cloud Logging already seems to support everything it describes.
Is there something in it that makes it a better solution in some way than what Google is already providing? (Note that Supabase Logs appears to rely on Google BigQuery so you'll be running on Google either way.)
You mentioned above that BigQuery reduces cost. I am surprised by that assertion, tbh. Can you point out ways in which Logflare uses it that makes it so (for ex, is it tiered-storage with a BQ front-end)?
How does Logflare's approach contrast with other entrants like axiom.co/99 who are leveraging blob stores (Cloudflare R2) for storage and serverless for querying for lower costs?
Multiple pluggable storage/query backends (like Clickhouse) is all good, but is there a default that Logflare is going to recommend / settle on?
Are there plans to go beyond just APM with Logflare (like metrics and traces, for instance)?
I guess, at some level, this product signals a move away from Postgres-for-everything stance?
What are some of the largest production applications built using Supabase? I know it's popular for whipping something up for a hackathon, but how battle tested is it?
Also does anybody know what they're doing behind the scenes with the database? I know their storage uses s3, functions (I think) use Deno, this uses BigQuery. Is their db on RDS/Aurora? If so how do they claim max DB size of 1024 TB while Aurora is 128 TB?
We have tens-of-thousands of applications using Supabase in production. "Size" is a hard one to answer because it means different things to different people. We have projects that have databases and storage in the hundreds-of-terrabytes, projects making millions of API requests, and logos from Fortune 100 companies.
If sentryio has a self hosted version and logflare has one too, why would I pick logflare? Are there any differences? I tried sentryio and it's really convenient, at least the hosted version.
Depends on your use case. If the volume of data you're looking at is not much, Sentry is more feature rich and refined.
If you want to expose a logging interface to your customers and/or easily integrate large volumes of structured event type data into the rest of your infra, then maybe look at Logflare.
One caveat: the only backend-store supported right now BigQuery. We will be releasing support for Clickhouse and Postgres in the coming months, we just couldn't fit it into this Launch Week
Supabase-specific SDKs are still in the works. However, if you're using the Logflare service as is, there is a pino transport[0] available for sending events directly to Logflare.
kiwicopple|2 years ago
this one is a long-time coming and it's a continuation of our acquisition of Logflare[0]. Since the acquisition we've be open-source-ing the server, which you can find here: https://github.com/Logflare/logflare
Logflare handles about 1.5 billion log-events everyday on supabase. It's built with Elixir and has no problems with that workload.
This is really just the start of the Logflare updates. All logs are currently ingested into BigQuery, and we are adding support for Clickhouse and other backends (focusing primarily on open source backend). Over time Logflare will function very much like an open source Sentry alternative, where you can ingest data from various sources.
The team will be around if you have any questions about the technical implementation
[0] acquision: https://supabase.com/blog/supabase-acquires-logflare
maxloh|2 years ago
What is the reason behind choosing Elixir?
ThePhysicist|2 years ago
csunbird|2 years ago
I do understand that you are hosting your stuff on AWS, which is subject to AWS egress fees, but the egress fee is just way too much for any serious project (imho)
swyx|2 years ago
this is asking a lot but could we get a breakdown as to what you think are relevant decision factors for choice of logging server? (eg vs logstash/kibana, splunk and i guess people DIY with clickhouse but we can effectively ignore that)
dale_glass|2 years ago
nextaccountic|2 years ago
I wish more companies were like this!
(note, the vector.dev link is broken)
kiwicopple|2 years ago
madjam002|2 years ago
francoismassot|2 years ago
We would need to support SQL though.
Just putting the link here: http://github.com/quickwit-oss/quickwit
Would love to have your feedback on ease of use/perf/whatever here/on twitter/discord (https://discord.quickwit.io/).
simonw|2 years ago
> Simply provide your BigQuery credentials and we stream logs into your BigQuery table while automatically managing the schema
I didn't know BigQuery was capable of accepting streaming log data - in my mental model of the world it was the kind of database that you update using the occasional batch job, not from a streaming source of data.
Looks like that's the tabledata.insertAll method which has been around for quite a few years - though it's now called the "legacy streaming API" on https://cloud.google.com/bigquery/docs/streaming-data-into-b... which suggests using the more recent Storage Write API instead: https://cloud.google.com/bigquery/docs/write-api
martin_|2 years ago
mtlynch|2 years ago
Supabase Logs / Logflare seems primarily interested in creating graphs from logs rather than using logs for diagnostic purposes.
I've been looking for a log solution that's good for the use case of high retention but low volume.
I have a few small apps that generate a few MB of logs per month, so basically nothing. But I still want to have all my logs searchable in one place.
Most logging solutions set retention based on time rather than data size. So regardless of how much you're logging, they throw away your logs within somewhere between 7-30 days unless you're on an insane Enterprise plan.
I was excited about LogFlare because it supports unlimited retention, but I ran into too many issues and had to cancel my subscription:
* To search your logs, you need to write a SQL-like query in LogFlare's DSL. You can't just put in a route (e.g. /api/auth) like you can with other log analytics.
* Search only shows the matching lines. Usually, what I want to see is the log line in context. For example, if I search "catastrophic error" I want to see the log lines leading up to that, not just that specific line.
* Search is limited to a maximum of 100 results. If you want to see more results, you need to rewrite your query rather than just scroll up or hit a "load more" button.
* When you do adjust the query to a larger time window, the query will fail because it can't generate a graph unless you also adjust the group_by in your query to match the new time window's limits. This is an annoying obstacle if you don't care about graphing the results and are just trying to diagnose an issue in your logs.
I found support lacking as well. I emailed support to ask if I was misunderstanding how to use Logflare or if it was just designed for a different use case. I was on a paid plan, but I still had to wait 3 business days for a response. When the response came, they just said that it was designed for me but didn't address any of the issues I brought up.
I do like that Logflare/Supabase let you bring your own BigQuery. That's nice for customers like me who want low-volume, high retention. I hope they continue iterating because it has potential.
In the meantime, I've found LogTail to be a pretty good alternative, but they're limited to 30 days of retention even on the highest tier plan.
chasers|2 years ago
Frankly these are all things I've wanted to address. We've just had to prioritize other tasks.
We're definitely going to keep iterating.
Thanks for taking the time to try it!
gvv|2 years ago
scottfr|2 years ago
Is there something in it that makes it a better solution in some way than what Google is already providing? (Note that Supabase Logs appears to rely on Google BigQuery so you'll be running on Google either way.)
wutania|2 years ago
wenbo|2 years ago
lyziinc|2 years ago
ignoramous|2 years ago
You mentioned above that BigQuery reduces cost. I am surprised by that assertion, tbh. Can you point out ways in which Logflare uses it that makes it so (for ex, is it tiered-storage with a BQ front-end)?
How does Logflare's approach contrast with other entrants like axiom.co/99 who are leveraging blob stores (Cloudflare R2) for storage and serverless for querying for lower costs?
Multiple pluggable storage/query backends (like Clickhouse) is all good, but is there a default that Logflare is going to recommend / settle on?
Are there plans to go beyond just APM with Logflare (like metrics and traces, for instance)?
I guess, at some level, this product signals a move away from Postgres-for-everything stance?
Thanks.
trialect|2 years ago
mdaniel|2 years ago
ralusek|2 years ago
Also does anybody know what they're doing behind the scenes with the database? I know their storage uses s3, functions (I think) use Deno, this uses BigQuery. Is their db on RDS/Aurora? If so how do they claim max DB size of 1024 TB while Aurora is 128 TB?
kiwicopple|2 years ago
We have tens-of-thousands of applications using Supabase in production. "Size" is a hard one to answer because it means different things to different people. We have projects that have databases and storage in the hundreds-of-terrabytes, projects making millions of API requests, and logos from Fortune 100 companies.
Nathanba|2 years ago
chasers|2 years ago
If you want to expose a logging interface to your customers and/or easily integrate large volumes of structured event type data into the rest of your infra, then maybe look at Logflare.
sidcool|2 years ago
kiwicopple|2 years ago
One caveat: the only backend-store supported right now BigQuery. We will be releasing support for Clickhouse and Postgres in the coming months, we just couldn't fit it into this Launch Week
notadeveloper|2 years ago
cpursley|2 years ago
Can we use Logflare as a generic logging service?
chasers|2 years ago
progx|2 years ago
lyziinc|2 years ago
[0]: https://github.com/Logflare/pino-logflare
kiwicopple|2 years ago