It sounds like you'll have to consult the prisma documentation to solve this issue. Apologies but we can only help with platform level issues. Thanks

How can I see how many connectons are currently being used and the limit of connections allowed by a hobby plan?

1. SELECT * FROM pg_stat_activity;

2. There is no connection limit based on the plan type, the connection limit of 100 comes from Postgres itself.

I'm using mysql, and I can't lower the idle time in connections. Is there a way to do it, so I don't have idle connections?

mysql> SET GLOBAL wait_timeout = 600;

Query OK, 0 rows affected (0,23 sec)

mysql> SHOW VARIABLES LIKE '%timeout%';

+-----------------------------------+----------+

| Variable_name | Value |

+-----------------------------------+----------+

| connect_timeout | 10 |

| delayed_insert_timeout | 300 |

| have_statement_timeout | YES |

| innodb_flush_log_at_timeout | 1 |

| innodb_lock_wait_timeout | 50 |

| innodb_rollback_on_timeout | OFF |

| interactive_timeout | 28800 |

| lock_wait_timeout | 31536000 |

| mysqlx_connect_timeout | 30 |

| mysqlx_idle_worker_thread_timeout | 60 |

| mysqlx_interactive_timeout | 28800 |

| mysqlx_port_open_timeout | 0 |

| mysqlx_read_timeout | 30 |

| mysqlx_wait_timeout | 28800 |

| mysqlx_write_timeout | 60 |

| net_read_timeout | 30 |

| net_write_timeout | 60 |

| replica_net_timeout | 60 |

| rpl_stop_replica_timeout | 31536000 |

| rpl_stop_slave_timeout | 31536000 |

| slave_net_timeout | 60 |

| ssl_session_cache_timeout | 300 |

| wait_timeout | 28800 |

+-----------------------------------+----------+

23 rows in set (0,23 sec)

Please see this page -

https://serverfault.com/a/1075835

Hey, did you managed to solve that?
I'm having the same issue with prisma and psql but ONLY on Metal infra. On the old system everything is working fine for me. Is it similar to what you have experienced?