llrt VS Redash

FROM --platform=arm64 busybox WORKDIR /var/task/ COPY app.mjs ./ ADD https://github.com/awslabs/llrt/releases/latest/download/llrt-container-arm64 /usr/bin/llrt RUN chmod +x /usr/bin/llrt ENV LAMBDA_HANDLER "app.handler" CMD [ "llrt" ]

Let’s get the simplest use case out of the way: cases where the cold starts are so fast that it’s not an issue for you. That’s usually the case for function that use runtimes such as C++, Go, Rust, and LLRT. However, you must follow the best practices and optimizations in every runtime to maintain a low impact cold start.

But compared to other runtimes, LLRT is not so good in terms of performance when it comes to dealing with large data processing, Monte Carlo simulations, or performing tasks with a large number of iterations. The AWS team says that it is best suited for working with smaller Serverless functions dedicated to tasks such as data transformation, real-time processing, AWS service integrations, authorization, validation, etc. Visit the GitHub repository of this project to learn more information.

And lastly, lean into your cloud vendor. Stop trying to build a better mouse trap. Advances in technology are happening all the time. The speed of AWS' Lambda has been rapidly improving over the past couple of years with the launch of things like SnapStart and LLRT

It seems they just added the mention to QuickJS, I assume, based on your feedback:

https://github.com/awslabs/llrt/commit/054aefc4d8486f738ed3a...

Props to them on the quick fix!

It seems like there may be an issue with Watchdog on Apple Silicon.

I am looking for service or tool similiar to Metabase or Redash that allows me to add data source - for example Postgres connection, and create raw SQL queries that can be shared or exposed through API. So instead of keeping raw SQL code somewhere, my other service would call this tool e.g. http://microservice/query=1?param1=xx&page=2 and get the results from the DB. These calls are internal only and part of ETL processes, but of course authentication would be required.

Yeah, a lot of the time I'd agree with you.

This container came about for the Redash project (https://github.com/getredash/redash), which has been stuck on PostgreSQL 9.5 (!) for years.

Moving to a new PostgreSQL container version is easy enough for new installations, but rolling that kind of change out to an existing userbase isn't so pretty.

For people familiar with the command line, PostgreSQL, and Docker then no worries.

But a large number of Redash deployments seem to have been done by people not skilled in those things. "We deployed it from the Digital Ocean droplet / AWS image / etc!"

For those situations, something that takes care of the database upgrade process automatically is the better approach. :)

I have tried Metabase, Redash beore (both self hosted open source versions), from my experience I find Metabase a bit easy to work with.

Regarding visualization tools, sqliteviz has proven to be the best I've found so far. Their web app runs locally but has some trackers, so I run it locally via a simple, static HTTP server. Falcon and Redash seem like overkill for my needs.

Redash seems to be dead or at least in hibernation. There hasn't been a release in over a year.

https://github.com/getredash/redash/issues/5891

redash